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ABSTRACT 


NPS  Combat  Systems  students  leam  systems  engineering  through  a  series  of 
courses  in  design,  development,  implementation,  and  testing  and  evaluation.  In  the  last 
of  this  series  of  courses,  students  design  an  autonomous  robot  capable  of  searching, 
acquiring,  and  tracking  another  autonomous  robot  having  similar  capabilities.  The 
project  culminates  in  the  Robot  Wars  Competition,  where  groups  of  students  have  their 
robots  battle  each  other. 

This  thesis  is  the  second  in  a  series  designed  to  realistically  simulate  the  robot 
wars  battles.  The  end-to-end  functionality  of  the  optical  detection  system  is  modeled, 
and  the  necessary  physics  are  implemented  for  effective  simulation  and  depiction.  The 
model  uses  a  transfer  function  approach  and  includes  all  physical  processes,  from  initial 
optical  beacon  emission  to  final  digital  control  signal.  Exercising  the  model  over  time 
using  realistic  robot  inputs  yields  a  simulation  that  closely  replicates  real  behavior.  A 
Virtual  Reality  Modeling  Language  (VRML)  program  uses  data  files  of  each  Simbot’s 
movement  to  generate  a  3 -dimensional  animated  scene  of  the  detection  sequence.  This 
implemented  optical  model  effectively  simulates  the  SE  3015  robot  optical  detection 
system  and  can  reproduce  an  actual  detection  and  tracking  sequence  between  two  robots. 
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I.  INTRODUCTION 


A.  OVERVIEW 

The  major  focus  of  the  Systems  Engineering  course,  SE  3015,  is  the  system 
engineering,  design,  testing,  and  evaluation  of  an  autonomous  robot  capable  of  searching, 
acquiring,  tracking,  and  attacking  another  autonomous  robot  having  similar  capabilities. 
The  course  itself  is  the  fcapstone  in  a  series  of  four  systems  engineering  courses  designed 
primarily  for  students  pursuing  a  Master’s  Degree  in  the  Combat  Systems  Science  and 
Technology  curriculum.  While  the  course’s  major  emphasis  lies  in  the  area  of 
microprocessor  architectures,  digital  communications,  and  digital  and  analog  interfacing, 
it  also  addresses  electromechanical  systems  used  for  closed-feedback  control  of 
positioning,  tracking,  and  detection  systems  in  autonomous  robots.  It  is  the  end-to-end 
physical  simulation  of  the  closed-feedback  positioning,  tracking,  and  detection  systems 
that  serves  as  the  focal  point  for  this  thesis  research. 

The  positioning,  detection,  and  tracking  hardware  issued  for  use  with  the 
autonomous  robot  in  the  SE  3015  course  includes  the  robot  base  platform,  a  small 
microprocessor  called  a  Tiny  Giant,  an  LED  beacon,  and  two  photodiodes.  The  robot 
base  platform  contains  two  dual  drive  servo-motors  which  give  the  robot  movement 
capability.  The  base  platform  includes  several  I/O  ports  which  allow  for  analog  to  digital 
(A/D)  conversion  of  external  data  which  may  be  used  for  robot  control.  The  LED  beacon 
acts  as  a  transmitter  and  is  the  device  which  each  robot  is  designed  to  detect  and  track. 
Each  beacon  can  be  set  to  flash  at  a  unique  frequency  within  the  5-25  kHz  range.  In  turn, 
students  are  each  assigned  one  of  the  unique  frequencies  for  his/her  robot  to  track.  Each 
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student  is  responsible  for  designing  and  building  a  detector  which  is  composed  of  an 
electrical  circuit  tuned  to  the  specific  frequency  for  which  their  beacon  flashes.  The 
detector  consists  of  a  set  of  photodiodes,  which,  upon  being  exposed  to  a  beacon  at  the 
tuned  flash  frequency,  supply  a  triggering  voltage  that  is  routed  to  ports  on  the  Tiny 
Giant,  which  perform  A/D  conversion.  A  personal  computer  connected  to  the  Tiny  Giant 
via  an  RS-232  cable  may  be  used  to  view  the  newly  converted  digital  reading  through 
execution  of  a  small  program  written  in  the  Dynamic  C  programming  language. 

Dynamic  C  also  allows  for  programs  to  be  written  which  endow  the  robot  with  total 
autonomous  control.  Figure  1-1  illustrates  the  above  mentioned  components. 


Figure  1-1 .  Schematic  of  optical  detection  system  used  on  robots  for  SE  3015  Robot  Wars 
competFition. 


This  thesis  builds  upon  previous  work,  [Jones,  1997],  in  providing  a  foundation 
for  the  accurate  simulation  of  a  two-robot  competition.  The  goal  for  the  final  model  is  to 
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serve  as  a  viable  aid  for  students  in  the  design,  testing,  and  evaluation  of  the  robot  during 
the  entire  systems  engineering  process.  The  previous  work  done  in  this  area  laid  an 
initial  foundation  for  a  computer  simulated  model  depicting  all  physical  behaviors  of  the 
robot  due  to  both  external  stimuli  and  internal  control  albeit  in  a  somewhat  rudimentary 
fashion,  focusing  on  visualization  and  data  recording.  This  thesis  focuses  specifically  on 
a  more  detailed  software  model  of  the  optical  detection  elements  in  addition  to  the  basic 
control  behaviors  of  actual  autonomous  robots  used  in  the  SE  3015  course. 

B.  MOTIVATION 

The  primary  motivation  for  this  study  arises  out  of  the  author’s  interest  in  the 
graphical  modeling  and  depiction  of  autonomous,  physical  systems.  This  interest  stems 
from  introductions  to  the  Combat  Systems  Robot,  NPS  Autonomous  Underwater  Vehicle, 
and  various  other  simulation  projects  undertaken  during  several  courses  in  physically 
based  modeling. 

Additional  driving  forces  behind  my  involvement  in  this  area  of  research  stem 
from  lessons  learned  during  the  testing  and  evaluation  phases  of  engineering  the  Combat 
Systems  Robot.  During  these  processes,  questions  always  arose, as  to  how  robot  design 
and  testing  might  be  made  easier.  My  response  always  seemed  to  entail  some  graphical 
model,  which  enabled  students  to  actually  design  and  test  their  robot  either  alone  or 
against  another  robot.  By  performing  tests  of  this  nature,  the  student  would  be  better 
equipped  to  visualize  the  projected  performance  that  the  robot  was  being  designed  to 
achieve. 
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C.  PURPOSE 


The  purpose  of  this  thesis  is  first  and  foremost  to  replicate  the  performance  of  the 
optical  transmission  and  detection  components  of  the  SE  3015  Combat  Systems  Robot. 
To  accomplish  this,  a  transfer  function  approach  has  been  taken  in  order  to  represent  each 
of  the  components  and  effects  involved  step-by-step,  from  the  initial  beacon  light 
emission  to  the  final  analog-to-digital  (A/D)  conversion.  Each  of  these  processes  has 
been  assessed  and  the  input  to  output  transfer  function  developed.  The  transfer  function 
approach  yields  a  modular  system,  for  modeling,  simulation,  and  experimentation,  where 
modules  can  be  independently  modified  if  robot  elements  change. 

Given  that  the  primary  purpose  of  each  component  in  the  detection  sequence  has 
been  assessed,  the  secondary  purpose  of  the  thesis  is  to  determine  which  of  the 
components  are  required  to  be  used  within  the  simulation  and  to  what  extent  they  must  be 
replicated.  Due  to  the  fact  that  the  detection  sequence  lies  at  the  very  heart  of  the  direct 
application  of  this  autonomous  robot,  such  determinations  go  a  long  way  in  aiding  future 
verification  and  validation  of  the  robot  models  with  respect  to  the  actual,  physical  robot. 

D.  THESIS  ORGANIZATION 

This  thesis  consists  of  detailed  physical  descriptions  and  characteristics  of  the 
optical  beacon,  detection  circuitry,  and  the  photodiodes.  It  then  describes  the  measured 
behavior  of  all  the  above  components  and  defines  an  input-to-output  transfer  function  for 
each.  Simulation  models  for  each  of  the  components  are  provided.  Component  models 
are  then  composed  to  produce  and  integrated  simulation  for  total  virtual  control, 
detection,  and  tracking  of  the  autonomous  robot. 
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Chapter  II  provides  details  of  previous  robot  wars  simulation  work.  Chapter  in 
gives  a  detailed  description  of  the  simulation  problem  addressed  in  this  thesis.  Chapters 
IV  and  V  provide  physical  descriptions  of  the  transmission  and  detection  components  of 
the  system,  including  their  theoretical  and  measured  behavior.  These  two  chapters  also 
define  the  input-to-output  signal  transfer  function  associated  with  each  component  and 
describe  how  the  component  models  are  simulated.  Chapter  VI  gives  a  synopsis  of  the 
transfer  functions  and  a  step-by-step  process  of  how  they  are  used.  Chapter  Vn  describes 
how  each  of  the  defined  transfer  functions  is  linked  for  comprehensive  simulation  of 
detection  and  tracking  of  a  robot.  This  chapter  also  discusses  the  software  and  code  used 
to  simulate  the  internal  and  external  behavior  of  the  robot.  Chapter  VUI  discusses  how 
each  of  the  transfer  functions  was  tested  and  how  the  overall  simulation  was  tested  for 
overall  performance.  Chapter  IX  describes  the  simulation  software,  its  components,  and 
how  to  use  it.  Chapter  X  presents  conclusions  and  future  work,  emphasizing  and 
extending  the  simulation  for  robot  testing  and  evaluation  modeling  in  the  SE  3015  Robot 
Wars. 
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II.  PREVIOUS  WORK 


A.  INTRODUCTION 

The  majority  of  the  initial  work  done  in  simulation  of  the  SE3015  Combat 
Systems  Robot  (Simbot)  is  described  '\n  Robot  Wars  Simulation  [Jones,  1997],  a  thesis 
which  lays  the  foundation  for  each  of  the  elements  needed  for  the  final  model.  In  that 
work,  Jones  describes,  in  detail,  the  physical  makeup  of  the  robot,  its  detection  sequence 
and  the  rules  and  boundaries  of  the  actual  Robot  Wars  Competition.  In  addition  to  a 
description  of  the  robot  components,  an  object-oriented  approach  is  used  to  outline  and 
characterize  each  of  these  components  in  the  C++  programming  language.  The  specific 
robot  components  on  which  the  work  focuses  are  the  robot  base,  its  optical  detection 
system,  and  its  standard  weapons. 

For  the  robot  base,  its  static  equations  of  motion  were  derived  and  the  commands 
which  allow  for  control  of  the  real  robot  were  “planted”  within  the  Simbot  so  that  it 
behaves  in  the  same  manner  as  its  real  counterpart.  For  the  optical  detection  system,  a 
basic  set  of  equations  was  used  to  compute  the  final  digital,  integer  number  produced  by 
the  A/D  converter  and  used  by  software  to  control  the  robot.  In  that  work,  the  initial 
integer  number  was  computed  based  on  the  range  and  angle  from  the  beacon  to  the  robot. 
For  the  robot’s  standard  weaponry,  basic,  static  based  equations  of  motion  were  used  to 
compute  projectile  motion  of  the  standard  ammunition  from  the  robot  to  its  target.  Other 
auxiliary  features  that  were  implemented  include  robot  collision  detection  and 
playing-field  edge  detection.  Each  of  these  components  was  programmed  within  a  single 
simulation,  which  implemented  and  gave  each  the  interconnectivity  required  for 
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depiction  of  robot  detection  and  acquisition  sequences.  That  thesis  concludes  with  a 
rudimentary,  graphical,  OPEN  GL  based  depiction  of  the  robot’s  engaged  in  the 
sequences  performed  in  a  Robot  Wars  Competition. 

B.  PRESENT  WORK 

For  this  thesis,  initial  work  began  in  the  CS  4472,  Physically  Based  Modeling, 
class.  In  this  class  the  author  and  two  other  Combat  Systems  students  who  had 
completed  the  SE  3015  course  derived  the  dynamic-based  equations  of  motion  for  the 
robot.  Although  the  accelerations  and  decelerations  values  are  theoretical,  this  allows  for 
future  students  working  in  this  area  to  actually  compute  these  values  based  on  realistic 
robot  behavior  and  directly  input  them  into  the  program  which  computes  the  positional 
values  of  the  Simbot  based  on  given  commands.  Additional  work  in  the  area  was 
conducted  during  the  authors  course  work  in  the  CS  4202,  Introduction  to  Graphics, 
class.  In  this  class  the  author  improved  upon  the  previous  graphical  depiction  of  the 
Simbot  and  its  features  using  the  Virtual  Reality  Modeling  Language  (VRML)  2.0  as  the 
graphical  tool.  The  positional  and  angular  data  computed  by  the  earlier  program  were 
used  within  the  VRML  program  as  an  engine  for  the  Simbot  to  move  within  its  “playing 
field”  world. 

In  this  thesis,  the  foundation  for  the  optical  detection  system  previously  created  is 
improved  by  including  detailed  modeling  for  each  system  component.  This  system 
model  is  interfaced  with  the  author’s  work  using  Jones’  program  connectivity  as  a  guide, 
for  the  purpose  of  graphically  visualizing  Simbots  engaged  in  various  optical  detection 
sequences. 
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C.  SUMMARY 


In  summary,  this  chapter  has  briefly  discussed  the  foundation  laid  in  the  area  of 
modeling  and  simulation  of  the  SE  3015  robots  as  well  as  the  Robot  Wars  competition. 
In  addition,  previous  work  done  in  this  area  by  the  author  was  discussed  along  with  the 
emphasis  of  this  thesis. 
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III.  PROBLEM  DESCRIPTION 


A.  INTRODUCTION 

This  section  addresses  the  specific  component  of  the  SE  3015  robot  of  which  this 
thesis  focuses  and  the  coinciding  simulation  problem. 

B.  SCOPE 

The  scope  of  this  thesis  is  to  accurately  simulate  the  search,  detect,  and  tracking 
functions  of  the  autonomous  robot  used  in  the  SE  3015  class  and  Robot  Wars 
Competition.  This  work  greatly  enhances  the  foundational  simulation  previously 
developed  by  improving  the  physics  for  a  specific  component  of  the  Simbot,  the  optical 
detection  system.  This  thesis  also  refines  the  graphical  or  virtual  depiction  of  the  Robot 
Wars  Competition  by  using  the  VRML  2.0  3-dimensional  (3D)  graphics  tool.  The  use  of 
VRML  also  allows  for  immediate  Internet  access  to  the  simulation  as  well  as  the 
possibility  of  future  networking.  The  goal  of  the  simulation  is  to  enable  one  to  compare 
and  analyze  the  design,  experimental  and  simulated  behavior  of  the  robot,  both  internally 
and  in  reaction  to  an  external  stimulus. 


C.  DETECTION  AND  TRACKING  SEQUENCE 

The  initiation  of  a  detection  and  tracking  sequence  begins  with  an  T  .F.D  beacon 
emitting  light  at  an  assigned  fi-equency,  which  is  detected  by  two  photodiodes  or  “eyes” 
of  a  robot.  The  diode,  in  turn,  produces  current,  which  is  the  following  circuit  converts 
into  a  voltage  and  filters  in  preparation  for  input  to  the  Tiny  Chant’s  A/D  converter.  The 
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Tiny  Giant  then  converts  the  analog  data  into  a  digital  number  to  be  used  in  robot  control 
software.  Because  the  inputs  and  outputs  of  the  various  sub-components  of  the  optical 
detection  system  are  vital  to  robot  control,  it  is  essential  that  the  simulated  components 
provide  a  high  degree  of  realism.  To  achieve  this,  the  determination  is  made  as  to  what 
components  must  be  modeled  and  to  what  fidelity  each  of  them  is  simulated  in  order  to 
provide  overall  simulation  accuracy,  while  not  having  excessively  long  computations. 
Once  the  required  components  were  identified,  a  signal-transfer  function  approach  was 
used  to  computationally  simulate  an  initially  transmitted  signal,  its  detection,  and  all 
subsequent  processing  to  yield  the  final  digital  number. 

As  previously  stated,  the  robot  receives  optical  signals  with  two  photodiode 
“eyes”.  The  robot  then  processes  the  signals,  converts  them  to  digital  form,  and  finally 
interprets  the  magnitudes  and  differences  to  determine  the  location  of  the  opponent.  The 
controller  drives  the  robot’s  response.  The  processor,  interpreter,  and  controller  logics 
and  software  implementations  are  designed  by  the  student.  Figure  3-1  illustrates  this 
concept. 

D.  SIMULATION  PERFORMANCE 

The  simulated  robot,  the  Simbot,  operates  in  somewhat  the  same  manner. 
However,  in  the  simulation  there  are  no  real  objects  or  signals,  and  the  position  of  the 
opponent  is  known.  Thus  the  simulation  must  replicate  the  performance  of  the  beacon 
and  the  resulting  light  intensities  received  by  the  eyes  due  to  beacon  distance,  opponent’s 
angular  location,  and  detector  eye  geometry.  The  simulation  does  not  modify  a  signal 
flowing  through  successive  circuits  as  the  real  system  does.  In  contrast,  it  applies  a  set  of 
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transfer  functions  to  the  end-to-end,  beacon  to  A/D  result.  The  final  information 
“passed”  to  the  simulation  interpreter  is  the  same  as  the  robot  A/D  signals.  The 
simulation  must  then  replicate  control  commands  as  designed  for  the  robot. 


Figure  3-1.  Diagram  of  simulated  detection  sequence.  The  Simbot  detects  the  li^t  trasmitted  from 
the  opponent's  simulated  beacon.  The  simulation  deals  only  with  the  hoxed  area. 
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As  with  all  high-level  programming,  an  abstraction  or  black  box  approach  is  taken 
where  the  user  is  intentionally  shielded  from  the  details  or  inner  workings  of  the 
simulated  model.  Because  of  this  approach,  the  user  is  not  sure  how  complex  the 
simulation  is,  but  is  aware  of  how  effective  the  model  is  in  representing  real,  physical 
behavior.  The  problem  at  hand  is  to  determine  how  accurately  each  of  the  components 
must  be  modeled,  both  individually  and  collectively,  so  that  they  adequately  depict 
reality. 

Each  robot  is  assigned  a  beacon  frequency  for  which  an  electrical  circuit  is  to  be 
designed,  built,  and  tuned  to  detect.  During  testing,  evaluation,  and  the  final  competition 
the  beacon  is  placed  at  some  arbitrary  position  level  with  the  robot’s  “eyes”  or  on  another 
robot’s  platform.  The  robot  is  then  activated  for  an  autonomous  sequence  of  searching, 
detection,  and  tracking  of  the  beacon.  The  simulation  seeks  to  keep  the  integrity  of  this 
sequence  of  events  intact,  offering  a  graphical  interpretation  of  the  process  while  doing 
so.  In  addition  to  the  detection  sequence,  the  actual  algorithms  and  programs  used  to 
control  the  robot  are  also  simulated  so  that  the  Simbot  reacts  to  its  external  stimulus  in 
the  same  manner  as  the  actual  robot  is  programmed  to  do. 


E.  SUMMARY 

In  summary,  this  thesis  accurately  models  the  LED  beacon,  robot  “eyes”,  and 
attached  electrical  circuitry  using  student  robot  input  parameters,  but  does  not  modify  any 
other  Simbot  methodology,  thus  leaving  the  remainder  of  Jones’  baseline  methodology  as 
originally  designed. 
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IV.  ROBOT  BEACON 


A.  INTRODUCTION 

This  chapter  discusses  the  transmission  component  of  the  optical  detection 
system.  It  addresses  the  beacon’s  physical  characteristics  and  both  its  theoretical  and 
measured  behavior.  The  chapter  concludes  by  defining  the  transfer  functions  for  each  of 
the  pertinent  transmission  elements  required  for  the  simulation. 


B.  PHYSICAL  CHARATERISTICS 

From  the  system  schematic  illustrated  in  Figure  1-1,  it  can  be  seen  that  the  robot 
beacon  is  the  first  component  in  the  optical  detection  sequence,  being  the  transmitter 
which  the  detector  is  tuned  to  acquire.  The  LED  beacon  placed  on  each  robot  is  the 
specific  object  that  is  detected  by  its  opponent.  Each  beacon  is  set  to  flash  at  a  unique 
fi'equency  generally  within  the  5-25  kHz  range.  The  frequencies  of  each  beacon  are 
separated  by  a  multiplication  factor  of  1.22,  with  the  lowest  beacon  frequency  assigned,  5 
kHz.  The  frequency  separation  allows  most  of  the  unwanted  harmonics  from  other  robot 
beacons  to  be  rejected.  A  CD4047  multivibrator  integrated  circuit  driven  by  a  nominal  6- 
volt  supply  is  used  to  produce  the  square  wave,  which  drives  the  beacon’s  flash. 

The  beacon  has  a  total  height  of  2.25”  and  a  radius  of  0.56”.  For  detection 
purposes,  the  beacon  is  placed  underneath  the  center  of  a  wooden  disk  located  3.5”-  4.5” 
above  the  top  of  the  Tiny  Griant.  The  beacon’s  light  distribution  pattern  is  360°  (i.e. 
omni-directional)  in  the  horizontal  plane.  In  the  vertical  plane  the  beacon’s  light 
distribution  pattern  is  ±5°  about  the  horizontal  plane,  for  a  total  of  a  10°  vertical  angular 
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Figure  4-1.  Beacon  positioning.  The  beacon  is  positioned  underneath  the  top  platform  of  the  robot's 
base  so  as  to  give  a  10°  total  vertical  spread. 


spread.  Figure  4-1  shows  how  the  beacon  is  positioned  on  the  robot.  The  only  physical 
entities  on  the  robot  which  obstruct  the  view  of  the  beacon  are  the  relatively  thin 
cylindrical  platform  supports  which  are  used  to  attach  the  wooden  disk  to  the  top  of  the 
Tiny  Giant. 

C.  THEORETICAL  BEHAVIOR 

The  light  emitted  from  the  beacon  may  be  compared  to  light  generated  from  an 
isotropic  medium  from  which  light  is  distributed  uniformly  in  all  directions  within  the 
horizontal  plane.  The  transmission  medium  through  which  the  light  is  propagated  is  air. 
Because  the  pattern  generated  by  beacon  light  distribution  is  spherical  in  nature,  the 
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beacon  is  taken  to  be  a  simple  source.  The  theoretical  intensity  of  the  beacon  light  as  a 
function  of  distance  is 


(4-1) 


where  Ib  is  the  source  intensity  of  the  beacon.  The  factor  1/r^  in  the  equation  represents 
the  decrease  in  received  intensity  with  distance  from  the  source. 

In  addition  to  the  behavior  of  beacon  intensity  as  a  function  of  range,  another 
beacon  characteristic  that  must  be  taken  into  consideration  is  the  frequency  at  which  the 
beacon  oscillates  and  its  dependence  on  the  beacon  oscillator  supply  voltage.  In  general, 
there  are  two  supply  voltage  options  that  may  be  used  to  power  the  oscillator.  The  first  is 
a  9-volt  battery  and  the  second  is  a  6- volt  battery  pack  composed  of  four,  1.5-volt  AA 
batteries.  For  each  of  these  options  some  drainage  of  the  battery  capacity  occurs  over 
time.  As  a  result  of  decreasing  battery  voltage,  there  is  expected  to  be  a  subsequent 
decrease  in  the  frequency  at  which  the  beacon  flashes.  A  corresponding  decrease  in  the 
intensity  of  the  beacon  is  also  expected. 


D.  MEASURED  BEHAVIOR 

For  the  purposes  of  the  ensuing  simulation,  each  of  the  above  mentioned  physical 
characteristics  was  measured  to  provide  quantitative  understanding  of  the  degree  of 
emphasis  necessary  for  accurate  depiction.  The  results  of  the  quantitative  measurements 
were  used  to  derive  a  transfer  function,  which  relates  the  pertinent  dependencies. 
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First,  a  photometer  was  used  to  attain  a  relative  measure  of  the  received  intensity 
generated  by  the  beacon  as  a  function  of  the  distance  from  the  source.  Two  sets  of  data 
were  taken.  The  first  set  of  photometer  readings  was  taken  in  a  relatively  dark 
environment.  This  was  done  in  an  attempt  to  separate  the  light  generated  by  the  beacon 
from  all  other  ambient  and  external  light  sources.  The  beacon  acted  as  the  source  of 
light,  and  the  photometer  acted  as  the  receiver.  The  photometer  was  placed  in  a  fixed 
position  relative  to  the  beacon.  The  beacon  was  then  moved  away  at  ranges  varying  from 
a  minimum  of  1”  to  a  maximum  of  20’,  which  approximates  the  maximum  range  of 


Figure  4-2.  Relative  photometer  intensity  readings  vs.  range.  The  experiment  was  conducted  under 
conditions  of  minimum  or  no  background  lighting.  The  graph  shows  data  for  distances  after  the 
maximum  saturation  range. 
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detection  during  a  robot  competition  detection  sequence.  Relative  intensity 
measurements  were  taken  at  6”  intervals. 

Figure  4-2  shows  the  results  of  the  experiment.  One  of  the  pertinent  features  of 
this  graph  is  that  the  normalized  intensity  ratio  maintains  its  maximum  value  of  1  out  to  a 
distance  of  3.5  feet.  This  infers  that  the  photometer  was  saturated  for  shorter  ranges. 

In  order  to  compare  the  intensity  distribution  as  a  function  of  range  with  the 
theoretical  1/r^  behavior,  the  data  from  the  curve  in  Figure  4-2  was  analyzed  from  the 
point  where  saturation  of  the  photometer  was  no  longer  present.  As  can  be  seen  from  the 
figure,  the  measured  data  bears  close  resemblance  to  the  expected  1/r^  behavior.  As  a 
result,  for  the  purposes  of  the  simulation,  the  intensity  as  a  function  of  distance  can  be 
modeled  as  1/r^. 

The  next  set  of  experiments  was  designed  to  determine  the  effects  of  a  second 
dependency  of  the  beacon  transmission,  the  flash  frequency.  Due  to  the  fact  that  a  supply 
voltage  drives  the  beacon  oscillator,  a  determination  of  the  voltages  that  provide  intensity 
as  a  function  of  range  had  to  be  made.  In  addition  to  these  performance 
characteristics,  the  affects  of  the  supply  voltage  on  the  frequency  and  intensity  had  to  be 
measured. 

The  first  experiment  measured  the  beacon’s  intensity  as  a  function  of  the  supply 
voltage.  In  this  experiment,  a  photometer  was  used  to  determine  the  relative  intensity  of 
the  beacon  as  the  beacon’s  power  source  was  decreased.  Measurements  were  taken  at 
ranges  of  5  and  10  feet.  Figure  4-3  shows  the  results  of  this  experiment.  As  can  be  seen 
from  the  figure,  at  supply  voltages  greater  than  4.5  volts,  the  intensity  of  the  beacon 

remained  constant.  However,  as  the  voltage  was  decreased  to  below  4.5  volts  there  was  a 
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Figure  4-3.  Relative  Beacon  intensity  as  a  function  of  supply  voltage.  Slopes  for  the  two  linear 
regions  shown  define  intensity  behavior  when  supply  voltage  is  less  than  4.5  volts. 


Steady  drop  of  intensity.  This  drop  persisted  until  the  light  from  the  beacon  was  totally 
diminished  at  about  1.6  volts.  With  either  of  the  battery  configurations  used  with  the 
beacon,  there  is  some  degradation  of  the  battery  output  voltage  with  time.  Analysis  of 
the  data  revealed  that  for  voltages  below  4.5  volts,  the  normalized  intensity  fall  off  may 
approximated  in  two  linear  regions  as  indicated  in  the  figure.  For  voltages  above  4.5 
volts  there  is  no  change  in  normalized  intensity.  Table  4-2  shows  the  slopes  and  their 
corresponding  regions. 

The  next  experiment  in  this  set  measured  the  voltage  drop  of  a  6-volt  battery  pack 
used  to  power  the  beacon  oscillator  as  a  function  of  time.  This  was  done  to  determine  the 
relative  decrease  in  voltage  over  a  time  interval  of  several  minutes  due  to  loading  from 
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M/AV 

Voltage  Range 

0.0 

9.0  volts  >  Vo  ^  4.5  volts 

0.133  volts'* 

4.5  volts  >  Vo  >  3.0  volts 

0.533  volts'* 

3.0  volts  >  Vo  >  1.5  volts 

Table  4-1.  Slopes  and  voltage  ranges  for  data  in  Figure  4-4. 


the  beacon  oscillator.  Due  to  the  fact  that  the  time  period  for  single  round  of  Robot 
Competition  is  3  minutes,  the  experiment  was  conducted  over  a  15-minute  time  interval 
to  measure  beacon  operation.  In  this  experiment,  four  brand-new,  1 .5-volt  AA  batteries 
were  used  in  the  battery  pack. 

A  multimeter  was  used  to  measure  the  oscillator  battery  voltage  and  a  stopwatch 
to  record  the  progressing  time.  The  battery  pack  had  an  initial  voltage  of  6.68  volts. 
Voltage  readings  were  taken  on  the  battery  pack  every  30  seconds  up  to  6  minutes  and 
then  every  1 -minute  up  to  a  maximum  time  of  15  minutes.  As  can  be  seen  from  the 
figure,  the  voltage  dropped  quite  rapidly  during  the  first  minute,  going  from  its  initial 
value  of  6.68  volts  to  6.32  volts.  During  the  next  four  minutes  there  was  a  fairly  steady 
drop  in  voltage  from  6.32  volts  to  5.99  volts.  The  next  eleven  minutes  had  a  relatively 
slow  voltage  drop  from  5.99  volts  to  5.66  volts. 

At  each  of  the  time  intervals,  the  frequency  resulting  from  the  decrease  in  voltage 
was  also  measured.  The  frequency’s  dependence  on  supply  voltage  is  shown  in  Figure 
4-5.  As  can  be  seen  from  the  figure,  the  frequency  decreases  with  decreasing  voltage. 
For  the  simulation,  the  frequency  decrease  is  approximated  as  being  linear.  The  slope  is 
used  to  calculate  the  decrease  in  frequency  as  a  result  of  the  oscillator  battery  voltage 
decrease.  The  slope  is  given  by 
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^  =  23.148  Hz  per  voU. 


(4-2) 
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Figure  4-4.  Oscillator  battery  voltage  as  a  function  of  time.  Test  conducted  using  four  1.5  volt  AA 
batteries,  under  minimum  loading  conditions. 

The  decrease  in  beacon  oscillator  battery  supply  voltage  over  time  and  resulting 
oscillator  frequency  decrease  for  any  detection  sequence  is  largely  dependent  on 
battery  loading  (i.e.  the  amount  of  current  supplied  by  the  battery).  For  the  data  shown  in 
Figures  4-4  and  4-5,  the  current  was  not  measured.  A  battery  pack  consisting  of  four  1 .5 
volt  AA  batteries  was  used  as  the  oscillator  supply  voltage.  The  beacon  oscillator  was 
the  only  load  placed  on  the  battery  pack.  For  the  simulation,  the  battery  drainage  over 
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time  was  approximated  using  straight-line  slopes  for  the  linear  portion  of  curves  of 
commercial  9-volt  batteries,  under  minimal  loading  conditions  of  20  mA,  for  time  periods 
under  two  hours. 

For  the  purpose  of  the  simulation,  the  user  is  allowed  to  select  from  four  different 
loading  conditions,  heavy  (H),  medium  (M),  light  (L),  and  no-load  (N),  for  batteries  used 


linear  region  used  was  from  6.6  to  5.8  volts.  Minim  battery  loading  is  assumed. 


with  the  Simbot.  The  default  condition  is  the  light,  20-mA  case.  Each  of  the  loading 
conditions  has  a  different  linear,  time-dependent  decrease  in  voltage  and  serves  as  an 
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approximation  of  various  loading  levels.  The  selection  of  an  increased  loading  condition 
results  in  a  faster  rate  of  decrease  in  supply  voltage  with  time.  This  faster  rate  of 
decrease  ultimately  effects  the  rate  at  which  the  oscillator  frequency  decreases.  If  more 
accurate  battery  voltage  discharge  and  loading  characteristics  are  desired,  the  current 
levels  should  be  measured  and  compared  to  voltage  discharge  curves  for  the  specific  type 
battery  used. 


Figure  4-6.  Voltage  discharge  characteristics  for  a  commercial  1.5-voIt  battery.  The  3  loading 
condition  discharge  curves  shown  are  used  to  simulate  heavy,  medium,  and  light  loading  conditions 
of  the  Simbot  detector. 


The  simulation  uses  the  slopes  of  linear  regions  for  battery  voltage  discharge 
curves  similar  to  that  shown  in  Figure  4-6.  The  matrix  in  Table  4-1  shows  the  allowed 
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user  selections  for  loading  conditions  along  with  slopes  used  for  each  condition.  Each  of 
the  values  listed  in  the  table  are  given  in  the  scenario  as  placeholders  so  that  they  may 
changed  if  other  measurements  are  made  or  other  batteries  are  used.  The  curves  for  a 
9-volt  commercial  battery  are  used  in  the  simulation  as  the  default  battery  type. 

Since  the  actual  beacon  used  in  the  Robot  Wars  competition  always  has  its  own 
battery  supply,  whose  only  load  is  the  beacon  oscillator,  the  light-loading  condition  is 
used  to  simulate  it.  The  slope  of  the  line  for  conditions  of  light  loading  of  a  9-volt  battery 
has  a  value  of  2.53  x  10'®  volts  per  second.  This  value  is  used  to  determine  the  change  in 
simulated  beacon  oscillator  voltage  with  elapsed  Simbot  operation  time.  The 


BATTERY  TYPE 

LOADING  CONDITION 

9-volt  battery 

H 

M 

L 

1.04  X  10"* 

5.56  X  10'^ 

2.53  X  10-' 

1.5-voIt  battery 

H 

M 

L 

5.56  X  lO'^ 

5.56  X  lO"^ 

2.78  X  10-^ 

Table  4-2.  Matrix  of  battery  types  and  loading  conditions  used  in  simulation.  The  values  listed 
below  the  loading  conditions  are  the  slopes  used.  The  slopes  are  given  in  units  of  volts  per  second. 


The  linear  portion  used  is  shown,  in  Figure  4-6,  as  a  line  imposed  on  the  20-mA  curve  for 
service  hours  less  than  10. 

E.  CONCLUSIONS  AND  RESULTING  TRANSFER  FUNCTIONS 

From  analysis  of  the  results  of  each  of  the  conducted  experiments,  it  may  be 
concluded  that  the  intensity  transmitted  by  the  beacon  may  be  characterized  by 
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Ib  —  Imax  *  Fr(VB), 


(4-3) 


where  /mo*  is  the  maximum  beacon  intensity  possible  under  conditions  of  maximum 
supply  voltage  and  h  is  the  transmitted  beacon  intensity,  which  is  dependent  on  Vb,  the 
beacon  supply  voltage.  Fi  is  the  related  transfer  function,  given  by 
Fi  =  1.0  -  AI,  (4-4) 

where  M  is  calculated  by  multiplying  the  beacon  battery  supply  change  in  voltage  by  the 
appropriate  slope  given  in  Table  4-2. 

In  addition,  the  beacon  flash  frequency  is  given  by 

fB  =  fo  -  Ff  (Vb),  (4  _  5) 

where/o  is  the  frequency  at  which  the  beacon  oscillator  is  initially  tuned  at  the  beginning 

of  a  detection  sequence  and /b  is  the  transmitted  beacon  frequency,  which  is  dependent 

♦ 

on  the  beacon  supply  voltage,  /^is  the  related  transfer  function,  given  by 
Ff  =  (4-6) 

where  Af  \s  calculated  by  multiplying  the  change  in  beacon  oscillator  voltage  by  the  slope 
given  in  Equation  4-2. 

As  stated  previously,  each  robot  is  assigned  a  unique  frequency,  which  the 
detector  is  designed  to  acquire.  The  results  of  the  experiment  conducted  Avith  and 
without  background  lighting  shows  the  reason  for  needing  to  include  the  beacon 
oscillator’s  frequency  dependence.  As  seen  in  Figure  4-2,  when  no  background  lighting 
was  utilized,  the  beacon  was  easily  seen  out  to  the  maximum  distance  of  20  feet. 
Additional  tests  revealed  that  when  background  lighting  was  present,  the  beacon  became 
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non-distinguishable  beyond  about  5  feet.  The  distinct  frequency  of  the  beacon  allows  the 
detector  to  easily  acquire  the  beacon  in  an  environment  which  may  consist  of  other 
emitting  beacons  and  additional  background  lighting.  A  small  change  in  beacon 
frequency  can  seriously  affect  robot  performance. 

From  the  results  of  the  beacon  intensity  as  a  function  of  range  experiments,  it  may 
be  concluded  that  the  beacon  intensity  range  dependence  may  be  approximated  as  1/r^  at 
ranges  between  the  maximum  saturation  distance  and  the  maximum  detection  ranges. 

For  the  simulation,  the  user  will  be  asked  to  supply  these  two  ranges.  The  normalized 
intensity  at  ranges  less  than  the  maximum  saturation  distance  is  1,  while  the  intensities  at 
ranges  greater  than  the  maximum  detection  range  are  given  as  0.  All  subsequent 
intensities  for  a  given  range  will  be  calculated  by  computing  the  normalized  intensity 
from  1/r^. 

This  chapter  shows  the  results  of  several  experiments  used  to  determine  the 
characteristics  of  the  transmission  beacon  required.  It  has  been  concluded  that  beacon 
intensity  and  frequency  must  be  simulated  for  adequate  replication  of  the  optical 
detection  sequence  of  the  SE  3015  Combat  Systems  Robot.  Furthermore,  the  beacon 
intensity  has  been  determined  to  be  a  function  of  its  flash  frequency  and  oscillator  supply 
voltage.  In  order  to  do  this,  the  time  dependence  of  the  oscillator  supply  voltage  must  be 
simulated. 

Finally,  in  order  to  pass  the  beacon  intensity  on  to  the  other  components  in  the 
sequence,  in  the  simulation,  the  following  steps  are  used.  First  of  all,  the  simulation  is  set 
up  using  user  input  initial  values  for  VbJo,  and  /„«*  at  t  =  0.0,  where  t  is  the  scenario 
time.  Additional  user  input  parameters  include  battery  type  and  loading  condition.  Using 
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these  inputs,  the  loading  condition  selects  the  appropriate  slope  for  the  battery  voltage 
degradation  v^rith  time.  Then,  given  some  t  >  0.0,  the  resulting  beacon  frequency  is 
calculating  from  Equation  (4-3)  and  the  intensity  calculated  from  Equation  (4-5). 
Procedures  for  measuring  the  required  input  parameters  are  given  in  Chapter  Vn. 

One  additional  dependency  on  the  received  intensity  is  that  of  the  intensity  of 
light  present  as  a  result  of  various  background  sources.  As  a  result  of  these  additional 
light  sources  which  produce  a  cumulative  intensity,  the  final  transmitted  intensity  is  given 
as 


It  =  Ib  +  In.  (4-7) 

where  /jvis  the  background  or  noise  intensity,  which  must  be  measured  by  the  user  and  is 
an  input  parameter  for  the  simulation. 

F.  SUMMARY 

This  chapter  discussed  the  optical  beacon  component  of  the  optical  detection 
system.  It  described  the  beacon’s  physical  characteristics  as  well  as  its  theoretical  and 
measured  behavior.  Transfer  functions  were  defined  that  allow  the  pertinent  signals 
transmitted  from  the  beacon  to  the  detector  to  be  effectively  modeled.  As  a  result  of 
these  transfer  functions,  the  simulated  beacon  transmits  two  time-dependent  and  voltage- 
dependent  quantities  to  the  Simbot,  the  beacon  intensity  and  the  beacon  frequency. 
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V.  DETECTION  SYSTEM 


A.  INTRODUCTION 

This  chapter  discusses  the  receiving  component  of  the  optical  detection  system.  It 
addresses  the  detector’s  physical  characteristics  and  both  its  actual  and  measured 
behavior.  The  chapter  concludes  by  defining  the  transfer  functions  for  each  of  the 
pertinent  detector  elements  required  for  the  simulation. 

B.  OVERVIEW 

The  detection  system  receives  the  light  transmitted  by  the  beacon  and  processes  it 
into  a  series  of  voltages  needed  to  produce  the  final  A/D  intensity  integer.  The  system’s 
detector  consists  of  two  major  sub-components,  its  detectors  (the  photodiode  “eyes”), 
which  actually  receive  the  light  and  the  processor,  which  does  the  required  signal 
processing.  This  chapter  describes  the  physical  positioning  of  the  “eyes”,  explains  the 
behavior  of  both  the  signal  processing  circuit  and  ^es,  and  additionally  defines  a  set  of 
signal  input-to-output  transfer  functions,  which  the  simulation  uses  to  transform  received 
intensity  into  an  integer  number,  emulating  the  A/D  converter. 

C.  DETECTOR  PHYSICAL  CHARACTERISTICS 

A  minimum  of  two  optical  diodes  must  used  on  each  robot  to  enable  it  with  range 
and  angle  discrimination.  Each  of  the  diodes  is  attached  to  its  own  signal  processing 
circuit,  which  enable  each  “eye”  to  see.  As  light  is  emitted  fi-om  the  beacon  and  received 
by  the  active  portion  of  the  diode,  current  is  generated  and  supplied  to  the  first  stage  of 
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the  processor.  The  active  portion  of  the  optical  diode  is  rectangular  in  shape.  The 
horizontal  length  is  0.28  in  and  the  vertical  height  is  0. 16  in.  The  total  effective  active 
area  is  0.045  in^.  The  eyes  are  usually  placed  on  the  front  of  the  robot  platform  with  the 
longest  side  of  the  active  diode  area  parallel  to  the  ground.  The  diodes  are  usually  placed 
at  a  height  at  which  the  active  area  may  still  receive  light  from  another  robot  given  robot 
distances  of  less  than  1  ft.  The  nominal  positioning  of  the  photodiodes  and  beacon  is 
illustrated  in  Figure  4-1.  As  previously  stated,  a  minimum  of  two  eyes  is  required  for 
each  robot.  The  two  eyes  are  usually  positioned  side  by  side  at  robot  centerline  and  are 
usually  separated  by  a  nose  barrier,  which  provides  angular  discrimination.  Figure  5-1 
shows  the  eye  and  nose  positioning.  As  can  be  seen  from  the  figure,  the  active  portion  of 


Figure  5-L  Overtiead  view  of  tyincal  eye  and  nose  barrier  configuration  for  SE  3015  robot  The 
photodiode  active  area  and  junction  leads  are  also  depicted. 
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the  diode  lies  underneath  a  glass  coating.  For  the  purposes  of  this  thesis,  it  is  assumed 
that  the  coating  has  no  lens  magnification  effects. 


D.  DETECTION  SYSTEM  BEHAVIOR 

Each  eye  used  on  the  robot  is  usually  attached  to  its  own  processor.  Other 
configurations  are  possible  which  use  a  single  processor  and  a  multiplexer  to  sample  the 
eye  output  signals.  The  processor  filters  and  processes  the  signal  received  fi-om  the  eyes 
in  such  a  manner  that  the  Tiny  Giant  may  use  it  for  A/D  conversion.  There  are  three 
major  components  in  this  circuit.  The  first  is  a  transimpedance  amplifier,  which  converts 
the  current  produced  by  the  photodiode  into  voltage.  The  transimpedance  amplifier  is 
connected  to  what  may  be  the  most  important  part  of  the  processor,  a  variable-state 
bandpass  filter,  which  is  tuned  to  resonate  at  the  assigned  beacon  flash  frequency.  This 
filter  has  a  variable  bandwidth  that  is  centered  on  (and  gives  maximum  response  at)  the 
tuned  fi-equency.  The  last  portion  of  the  processor  is  a  half-wave  rectifier,  the  rectified 
signal  being  what  the  Tiny  Giant’s  A/D  converter  converts  into  integer  numbers  upon 
which  command,  control,  and  detection  algorithms  are  based. 

The  A/D  converter  converts  the  analog  voltage  into  an  integer  number  ranging 
fi-om  16  to  4080.  The  lower  number  represents  the  minimum  signal  present  when  there  is 
no  detection.  When  a  minimum  amount  of  noise  is  present,  the  integer  numbers  fluctuate 
between  16  and  32.  A  minimum  beacon  detection  signal  produces  a  nominal  reading  of 
48,  which  represents  100%  probability  of  detection  in  the  software  detection  logic. 
Ambient  light  levels  which  produce  a  reading  greater  than  48  will  interfere  with 
detection.  The  high-end  reading  of 4080  represents  the  maximum  signal  strength.  The 
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numbers  generated  between  48  and  4080  are  largely  dependent  on  the  range  of  the 
beacon  from  the  diode  and  the  angle  at  which  the  light  is  incident  on  the  active  portion  of 
a  robot  eye.  Other  factors  that  may  impact  the  readings  generated  by  the  A/D  converter 
are  the  processor  gain,  the  ratio  of  beacon  frequency  to  tuned-processor  frequency,  and 
the  beacon  intensity.  The  beacon  and  detector  system  supply  voltages  also  affect  these 
parameters. 

For  the  purpose  of  the  simulation,  it  is  believed  that  the  most  important  part  of  the 
processor  is  the  bandpass  filter.  The  typical  bandpass  filter  used  by  the  SE  3015  classes 
is  of  the  variable  state  form,  shown  in  Figure  5-2.  As  can  be  seen  from  the  figure,  four 
operational  amplifiers  (op-amps)  are  used  in  combination  with  a  number  of  critical 


figure  5-2.  Schematic  of  typical  bandpass  filter  used  in  SE  3015  course  for  detection  of  beacon 
frequency.  This  circuit  allows  resonance  frequency,  gain,  and  bandwidth  to  be  set  independently  of 
one  another. 


resistors  and  capacitors.  The  advantage  of  this  circuit  is  that  the  resonance  frequency, 
bandwidth,  and  gain  may  each  be  set  or  changed  with  a  single  resistor  and  additionally 
each  setting  is  independent  of  the  other.  As  previously  stated,  the  resonance  frequency  is 
the  assigned  beacon  frequency.  The  bandwidth  is  optional,  but  is  typically  designed  to 
give  a  quality  factor  equal  to  50-100  for  optimum  performance.  The  quality  factor,  Q,  is 
defined  as 


/o 


A/’ 


(5-1) 


where/o  is  the  resonance  frequency  and  A/^is  the  bandwidth.  The  Q  gives  the  relative 
sharpness  of  the  voltage  or  current  frequency  response  curve.  Figure  5-3  shows 


Figure  5-3.  Frequency  response  curve  for  detector  bandpass  filter.  The  figure  shows  curves  and 
half-power  points  for  corves  with  Q  of  50  and  100. 
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the  measured  frequency  response  of  the  circuit  used  for  the  simulation.  As  can  be  seen 
from  the  figure, /y  and/2  are  the  frequencies  where  the  voltage  drops  off  by  a  factor  of 
0.707  (3  dB  down  points). 

For  simulation  purposes,  the  assumption  is  made  that  the  only  internal  factor 
affecting  the  photodiodes  is  the  processor  supply  voltage.  This  voltage  will  decrease 
with  time  due  to  current  drain.  The  decrease  in  voltage  will  cause  a  subsequent  reduction 
in  the  performance  of  the  photodiodes.  Several  experiments  were  conducted  on  the 
photodiodes  so  that  a  fairly  accurate  dependence  on  circuit  supply  voltage  could  be 
determined. 

E.  MEASURED  BEHAVIOR 

For  the  purposes  of  the  ensuing  simulation,  each  of  the  detector  factors  discussed 
above  was  measured  or  analyzed  in  order  to  determine  the  relevancy  of  each  to 
simulation  performance  and  to  develop  its  transfer  function.  After  designing  and 
operating  the  processor  with  the  actual  robot,  it  has  become  evident  that  the  only 
parameters  and  data  needed  for  its  accurate  replication  are  those  dealing  with  its  filter  and 
its  voltage  gain  dependency. 

The  frequency  response  of  the  circuit  was  measured  by  using  a  signal  generator  to . 
apply  a  signal  of  a  few  millivolts  to  the  input  of  the  bandpass  filter.  The  output  of  the 
remainder  of  the  circuit  (input  to  A/D  converter)  was  examined  using  an  oscilloscope.  A 
half-wave  rectified  waveform  was  produced  as  expected.  As  the  frequency  of  the  input 
signal  was  increased  or  decreased  from  the  resonance,  the  output  was  observed  to  ensure 
that  the  voltage  of  the  output  waveform  “rolled  off”  as  predicted.  At  both  half-power 
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points,  the  voltage  dropped  by  a  factor  of  0.707  when  the  frequency  came  within  ±  0. 1 
kHz  of/y  or  f2.  The  same  behavior  and  results  were  observed  for  quality  factors  ranging 
from  50-100  in  other  tests.  For  an  assigned  frequency  of  16.5  kHz  and  a  Q  of  50,  the 
bandwidth  is  330  Hz,  giving/;  and/^  of  16.435  kHz  and  16.665  kHz  respectively. 

In  order  to  determine  the  effects  of  voltage  gain  on  processor  output,  a  set  of  three 
separate  experiments  was  conducted  where  the  gain  of  the  circuit  was  adjusted  to  three 
different  levels:  10, 20  and  40.  A  single  photodiode  was  placed  on  a  stand  situated  on  a 
smooth  plane  at  a  height  of  6”  from  the  groxmd.  A  beacon  was  then  situated  on  a  similar 
stand  so  that  the  center  of  its  active  portion  was  the  same  height  from  the  ground  as  the 
diode.  The  beacon  was  then  moved  from  distances  ranging  from  6”  to  20’  at  intervals  of 
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taken  at  each  of  the  ranges.  The  results  of  this  set  of  experiments  are  shown  in  Figure 
5-4, 

From  the  figure,  it  can  be  seen  that  the  gain  of  the  circuit  primarily  affects  two 
things,  the  saturation  distance  (distance  at  which  maximum  signal  is  read)  and  the 
maximum  range  of  detection.  With  a  gain  of  10,  the  measured  saturation  distance  was 
2.5’and  the  maximum  detection  range  was  6’.  When  the  gain  was  doubled  to  20,  the 
measured  saturation  distance  increased  to  3.2’  while  the  maximum  detection  range 


Figure  5-5.  Comparison  of  A/D  reading  vs.  range  and  expected  l/i^  behavior. 


increased  to  about  12’.  When  the  gain  was  once  again  doubled,  to  40,  the  measured 
saturation  distance  increased  to  about  4’  while  the  maximum  detection  range  increased  to 
about  20’. 

For  each  of  the  experiments,  the  A/D  readings  versus  range  curves  have  a  1/r^ 
behavior  from  the  maximum  distance  of  saturation  to  the  point  where  the  maximum 
detection  signal  was  measured.  This  indicates  that  the  detection  system  is  linear,  so  that 
an  end-to-end  transfer  function  can  be  used.  Figure  5-5  shows  the  curve  for  a  gain  of  40 
and  the  expected  1/r^  behavior. 


The  next  experiment  involved  determining  the  effect  of  supply  voltage  on  the 
detector  system.  For  this  experiment,  a  dual  source  was  used  to  supply  the  processor 


Figure  5-6.  Effects  of  supply  voltage  on  detector  circuit  The  experiment  was  conducted  with  beacon 
at  distances  of  1, 5  and  10  feet  away  from  detector. 
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with  its  required  positive  and  negative  voltages.  A  single  eye  was  placed  in  a  fixed 
position  and  the  beacon  was  placed  directly  in  front  of  the  eye  and  moved  to  distances  of 
r,  5’  and  10’.  The  output  of  the  detection  system  was  measured  at  each  of  these 
distances  while  the  supply  voltage  was  decreased  in  increments  of  0.5  volts.  Figure 
5-6  shows  the  result  of  the  experiment  for  distances  of  5  ft.  and  10  ft. 

As  can  be  seen  from  the  graphs,  the  decrease  in  output  due  to  the  reduction  in 
supply  voltage  has  a  rather  linear  profile  at  each  of  the  ranges  where  measurements  were 
taken.  When  the  supply  voltage  was  decreased  below  3  volts,  no  signal  could  be 
detected.  In  this  case,  there  was  a  voltage  present  at  the  output  stage  of  the  circuit, 
however  when  the  eye  was  completely  covered  the  voltage  did  not  change,  indicating  that 
the  circuit  was  no  longer  capable  of  detecting  a  signal.  For  the  simulation,  a  linear 
approximation  to  these  curves  was  used. 

In  summary,  two  experiments  have  been  conducted.  The  first  experiment  shows 
that  the  measured  A/D  readings  as  a  function  of  range  hold  a  1/r^  dependency.  The 
second  experiment  measured  the  effects  of  the  processor’s  input  voltages  on  eye- A/D 
readings.  From  this  experiment  it  was  conclusively  shown  that  the  input  voltage  has  a 
linear  effect  on  the  A/D  readings  at  a  given  range.  The  slope  of  the  linear  region  of  the 
supply  voltage  vs.  normalized  circuit  output  data  having  a  value  of  0.0391  volts'*  and 
shown  in  Figure  5-6,  is  used  to  compute  the  change  in  processor  output  as  a  result  of 
battery  voltage  degradation.  The  slope  of  the  linear  region  for  a  range  of  10  ft.  was  used 
because  at  this  range  the  processor  output  5delded  the  highest  values  at  ranges  both 
greater  and  smaller  than  10ft.  source  distance. 
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F.  EXTERNAL  FACTORS 


The  detector  behavior  previously  discussed  is  largely  attributed  to  the  internal 
parameters  and  characteristics  of  the  processor.  However,  the  one  external  factor  that 
was  discussed  is  the  intenshy  received  by  the  detector  as  a  function  of  range.  From 
Figure  5-4  it  can  be  seen  that  once  the  maximum  saturation  distance  is  reached,  the 
received  beacon  intensity,  as  a  function  of  range  only,  behaves  as  1/r^.  As  a  result  of  this 
distribution,  the  equation  relating  the  transmitted  intensity  to  the  received  intensity  is 
given  by 


~^T  *‘^A  >  (^~2) 

where  Ta  is  the  transmission  factor,  a  fractional  value  based  on  the  transmission  medium. 
Table  5-1  gives  the  values  of  Ta.  In  the  table,  r  is  the  range  of  the  beacon  from  the 


CONDITION 

VALUE  OF  Ta 

r  <  rs 

1 

Vs  ^  T  T ffiax 

r  >  rmax 

0 

Table  5-1.  Table  showing  values  of  Ta  for  corresponding  range  conditions. 


detector,  /-j  is  the  maximum  distance  at  which  the  “eyes”  are  saturated,  and  rmax  is  the 
maximum  range  at  which  the  detector  can  detect  the  beacon  light.  Each  of  these 
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variables  is  an  input  parameter.  The  method  for  measuring  each  variable  is  described  in 
Chapter  Vn. 

The  positioning  and  resulting  geometry  of  photodiode  positioning  account  for 
additional  external  effects,  which  play  a  large  role  in  determining  the  intensity  integer 
produced  by  the  A/D  converter.  As  previously  stated  and  depicted  in  Figure  5-1,  the 
robot  “eyes”  are  usually  positioned  adjacent  to  each  other  and  are  separated  by  a  nose  of 
some  length  to  determine  which  side  the  beacon  light  is  being  detected  from.  In  addition 


Figure  5-7.  Diagram  showing  positioning  of  eyes  and  nose  to  include  angles  and  distances  that 
account  for  shadowing  and  discrimination. 

to  the  expected  single  photodiode  angular  dependence  on  the  incident  angle  of  the  beacon 
light,  the  ratio  of  nose  length  to  eye  distance  from  nose-base  ratio  presents  another  set  of 
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angular  dependencies  and  subsequent  effects.  Figure  5-7  shows  the  set  of  angles 
introduced  by  the  addition  and  use  of  a  nose. 

For  the  purpose  of  the  simulation,  it  has  been  assumed  that  the  set  of  eyes  is  a 
single  point  on  the  robot  so  that  one  incident  angle  is  used  for  both  eyes.  Using  this 
assumption,  if  no  nose  were  used,  each  eye  would  receive  the  same  amount  of  light  and 
consequently  there  would  be  no  way  to  determine  which  side  relative  to  the  robot  the 
source  is  positioned.  As  a  result,  no  decipherable  information  could  be  used  for  robot 
control. 

The  angle  of  incidence,  0,  is  the  angle  at  which  the  light  from  the  beacon  falls  on 
the  active  portion  of  the  photodiode.  The  intensity  as  a  result  of  reduction  in  effective 
area  subtended  is  given  by 

le  =  lit* cose  .  (5-3) 

In  this  equation,  Ir  is  the  light  intensity  received  from  the  beacon  and  0  is  the  incident 
angle. 

With  the  addition  of  a  nose,  if  the  source  were  positioned  on  either  side  of  the 
nose  centerline,  one  eye  receives  the  total  amount  of  incident  light  while  the  other  is 
shielded  from  the  light  to  some  degree.  This  relationship  is  illustrated  in  Figure  5-7.  As 
can  be  seen  from  the  figure,  the  extreme  ends  of  the  photodiode  active  area  limit  the 
amount  of  light  received  by  an  eye.  An  eye  positioned  on  the  same  side  as  the  source 
receives  the  full  amount  of  incident  light,  depending  on  its  angle  of  incidence.  The  other 
eye  receives  the  same  amount  of  light  as  the  first  only  if  the  angle  of  incident  light  is  less 
than  0mi„,  where  0min  is  given  by 
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(5-4) 


0  mk,= tan''  , 

^nose 

where  dmin  is  the  measured  distance  between  the  inner  extreme  of  the  photodiode  active 
area  and  the  base  of  the  nose  and  l„ose  is  the  measured  length  of  the  nose.  If  the  angle  of 
incident  light  is  greater  than  0max,  the  eye  receives  none  of  the  incident  light.  The  angle 
Omax  is  given  by 

(S-S) 

^  nose 

where  dmax  is  the  measured  distance  between  the  outer  extreme  of  the  photodiode  active 
area  and  the  nose  base  and  is  given  by 

dmax  ~  dmin  "i”  ^ 

In  Equation  5-6,  /  is  the  total  length  of  the  photodiode  active  area.  The  derived  formula 
that  gives  the  fraction  of  intensity  received  is  given  by 

/,  f«r0^<0<0^,  (5-7) 

where  /,  is  the  intensity  received  as  a  result  of  shading  and  h  is  the  intensity  received  as 
only  a  result  of  its  angular  dependence.  If  the  angle  of  incident  light  falls  between  the 
two  angles,  then  the  intensity  of  incident  light  is  shaded  to  some  degree  based  on  the 
amount  of  photodiode  active  area  actually  being  shielded  from  the  incident  light  by  the 
nose.  The  L  in  Equation  (5-7)  is  given  by 

L  =  (S-8) 
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Thus,  Equation  5-7  gives  how  much  of  the  photodiode  active  area  is  actually  being 
shaded. 

G.  CONCLUSIONS  AND  RESULTING  TRANSFER  FUNCTIONS 

From  the  measurements  made  on  the  factors  affecting  the  detector,  a  series  of 
signal  input-to-output  transfer  functions  may  now  be  defined.  It  has  been  concluded  that, 
for  the  purposes  of  the  simulation,  the  intensity  received  by  either  of  the  “eyes”  is 
primarily  a  function  of  three  internal  entities.  The  first  two  factors  are  the  detector 
intensity’s  dependence  on  both  range  and  incident  angle,  as  discussed  in  the  previous 
section. 

The  third  factor  is  the  detector’s  dependency  on  the  voltage  supplied  to  the 
processor,  where  the  signal  input  to  output  function  is  given  by 

/d  =  4  *  Fn(VD),  (5-9) 

where  Id  is  the  intensity  received  by  the  detector,  which  is  dependent  on  the  supply 
voltage  and  Ir  is  the  intensity  that  would  be  received  if  there  were  no  voltage  effects.  Fpj 
is  the  relating  transfer  function  and  is  given  by 

Fpj  =  1.0  -  AP„m„  (5-10) 

where  the  change  in  processor  output  and  is  calculated  by  multiplying  the 

change  in  detector  supply  voltage  by  the  slope  of  the  linear  region  represented  by  the  data 
in  which  the  source  was  10  ft.  fi-om  the  detector,  as  shown  in  Figure  5-6.  The  quantity 
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yielded  by  the  transfer  function  tells  the  percentage  of  Ir  remaining  intact  given  the 
reduction  in  detector  supply  voltage.  The  line  slope  yields  a  value  of  0.0391  volts'^ 

The  detector  battery  supply  is  affected  in  the  same  manner  as  the  beacon 
oscillator  battery  supply.  The  matrix  shown  in  Table  4-1  is  used  to  select  the  battery  type 
and  loading  condition  as  before.  The  simulation  defaults  are  9  volts  for  battery  type  and 
light  loading.  As  a  result,  the  detector  battery  supply,  Vd,  is  given  by 

Vd  -  VD(t=0)  -  (5.56  X 10^  volts/sec  *  At),  (S-11) 

where  At  is  the  elapsed  scenario  or  detection  system  operation  time. 

The  fourth  critical  factor  affecting  the  detector  intensity  is  the  frequency  of  the 
flashing  beacon  light.  As  previously  stated,  the  beacon  is  tuned  to  an  initial  frequency 
that  decreases  with  time.  The  detector’s  circuit  is  tuned  to  the  initial  frequency.  The 
frequency  response  curve  shown  in  Figure  5-3  shows  how  the  circuit  responds  to  various 
input  frequencies.  The  equation  giving  a  signal  input  to  output  relationship  is  given  by 

(5-12) 

In  this  equation,  7/ is  the  Gaussian-like  transfer  function  that  gives  the  desired  frequency 
response  of  the  circuit  and  is  given  by 

W’\ 

Tf  =  exp((-'-^)),  (5-13) 

2<J 

where  A/"  is  the  difference  between  the  difference  between  the  received  beacon  flash 
frequency,/^  and  processor’s  tuned  frequency,^;  and  a  is  the  characteristic  width  of  the 
frequency  response  curve.  The  characteristic  width  is  set  so  that  when  Af=0,  the  received 
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intensity  is  maximum;  and  when  A/'w  V2  of  the  desired  bandwidth,  the  intensity  is 
reduced  by  a  factor  of  0.707.  Thus,  o  is  defined  by 


0-14) 

where  f tuned  is  the  fi*equency  to  which  the  processor  is  tuned. 

The  last  critical  factor  affecting  the  received  detector  intensity  is  the 
discrimination  and  shadowing  effect  discussed  earlier.  This  factor  is  also  important 
because  it  allows  for  two  different  values,  one  for  each  “eye”,  to  be  yielded  fi-om  a  single 
given  input  intensity.  The  function  relating  the  input  intensity  received  by  the  set  of 
“eyes”  to  the  output  intensity  received  by  each  eye  is  given  by 

=Id(  ( 0,  /,  dnwt,  Imue)).  (S  -  15) 

In  this  equation,  T,hadow  is  the  transfer  function  that  uses  equation  (5-5)  to  determine 
shadowing  effects  for  the  “eye”  that  is  not  on  the  same  side  as  the  source. 


H.  SUMMARY 

This  chapter  discussed  the  detector  component  of  the  optical  detection  system.  It 
described  the  detector’s  physical  characteristics  as  well  as  its  actual  and  measured 
behavior.  Transfer  functions  were  defined  that  allow  the  pertinent  signals  received  and 
processed  by  the  detector  to  be  effectively  modeled.  As  a  result  of  these  transfer 
functions,  it  has  been  concluded  that  for  an  effective  simulation  there  are  only  five 
internal  and  external  detector  factors  that  must  be  considered.  These  factors  are:  (1)  the 
angular  dependence  of  the  incident  light,  (2)  the  range  of  the  beacon  fi-om  the  detector. 
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(3)  the  effects  of  voltage  on  the  processor,  (4)  the  circuit’s  frequency  response  and  (5)  the 
effects  of  shadowing  and  eye  discrimination. 


VI.  TRANSFER  FUNCTION  SYNOPSIS 


A.  INTRODUCTION 

This  chapter  organizes  and  redefines  each  of  the  transfer  functions  defined  in  the 
previous  two  chapters  so  that  they  might  effectively  simulate  the  step-by-step  process  of 
an  SE  3015  optical  detection  sequence. 

B.  OVERVIEW 

As  previously  stated,  the  purpose  of  this  thesis  is  to  accurately  replicate  the 
optical  detection  sequence  of  the  robots  used  in  the  SE  3015  Robot  Wars  competition  in  a 
computer  simulated  model.  In  accomplishing  this,  the  various  components  of  the  robots 
have  been  described  along  with  defined  signal  input  to  output  transfer  functions  for  each 
of  the  pertinent  components.  The  use  of  these  transfer  functions  allows  one  to  produce  a 
signal  output,  in  terms  of  an  A/D  integer  number,  that  represents  a  dependency  on  each  of 
the  important  internal  and  external  factors  of  both  the  beacon  and  detector. 

In  order  to  use  the  transfer  functions,  a  method  of  applying  each  of  transfer 
functions  must  also  be  developed.  The  robot  command,  control,  and  detection  algorithms 
utilize  the  A/D  integers  produced  from  each  eye,  interpreting  a  range  and  angle 
dependence  (r,0)  to  the  opponent’s  robot.  As  a  result,  the  simulation  assumes  the  range 
and  relative  angle  from  the  combatant  Simbot  to  the  referenced  Simbot  are  known  at  each 
time  step  during  the  detection  sequence.  Thus,  a  method  of  making  corrections  to  the 
final  A/D  integer  is  used  rather  than  operating  on  internal  system  signals  with  functions. 
The  final  A/D  integer  is  used  by  the  simulation  for  Simbot  operation  and  display. 
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C.  TRANSFER  FUNCTION  FLOW 


Since  it  is  the  final  A/D  integer  that  the  simulation  uses,  the  user  is  asked  to  input 
the  value  of  the  maximum  A/D  integer  that  the  robot  detector  is  capable  of  producing.  It 
has  been  assumed  that  both  detectors  have  been  calibrated  so  that  the  integer  reading  is 
the  same  for  both  eyes.  Procedures  for  obtaining  the  maximum  A/D  integer  and  all  other 
required  input  parameters  are  discussed  in  the  next  chapter.  The  remainder  of  this 
chapter  discusses,  step-by-step,  how  each  of  the  equations  and  transfer  functions  are  used 
in  the  simulation  to  produce  the  ultimate  A/D  integer  reading  for  each  eye. 

As  occurring  on  the  actual  robot,  the  detection  sequence  is  initiated  with  an 
emission  of  light  fi'om  the  beacon  at  some  intensity  and  frequency.  For  this  beacon 
emission,  two  transfer  functions  have  been  defined;  one  for  the  beacon’s  intensity  and 
another  for  its  fi’equency.  The  beacon  intensity,  h,  is  characterized  by 

Ib  —  Imax  *  Fi(Vb),  (6-1) 

where  Imax  is  the  maximum  beacon  intensity  possible  under  conditions  of  maximum 
supply  voltage.  Ib  depends  on  Vb,  the  beacon  supply  voltage  and  Fj  is  the  related  transfer 
function.  This  transfer  function  uses  the  slope  of  the  linear  portion  of  a  curve  like  the  one 
shown  in  Figure  4-7  to  calculate  the  change  in  supply  voltage  with  elapsed  beacon 
operation  time.  The  slope  of  the  linear  portion  of  the  curve  is  given  by  the  default  light 
loading  condition  and  9-volt  battery  case  as 

AV 

— —  =  5.56  X 10'^  volts/sec,  (6-2) 

At 
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where  LVb  is  the  change  in  beacon  oscillator  battery  voltage  and  At  is  the  elapsed 
scenario  or  beacon-operation  time.  Slopes  for  other  batteries  and  loading  conditions  are 
given  in  Table  4-1.  The  data  in  Figure  4-7  was  used  to  define  the  transfer  function,  Fi, 
which  gives  the  factor  by  which  the  maximum  normalized  intensity  of  the  beacon  has 
decreased  as  a  result  of  a  decrease  in  supply  voltage.  The  transfer  function  is  given  by 

Fj  =  1.0  -  AI,  (6-3) 

where  AI  is  calculated  by  multiplying  the  change  in  beacon  supply  voltage  by  one  of  the 
slopes  given  by  the  linear  regions  of  Figure  4-7.  Two  of  the  three  different  regions  used 
have  been  outlined  on  the  figure.  The  slopes  and  their  respective  voltage  regions  are 
given  in  Table  4-1. 

In  addition  to  the  simulated  beacon  intensity,  the  simulated  beacon  flash 

frequency  must  also  be  transmitted  to  the  detector.  The  simulated  frequency  is  given  by 

* 

fB  =  fo  -  Ff  (Fb),  (6-4) 

where/o  is  the  frequency  at  which  the  beacon  oscillator  is  initially  tuned  at  the  beginning 
of  a  detection  sequence.  The  term  fs  is  the  transmitted  beacon  frequency,  which  is 
dependent  on  the  beacon  supply  voltage  and  iy  is  the  related  transfer  fiinction.  The 
transfer  function  is  given  by 

Ff  =  AVb  /  23.15  Hz  per  volt,  (6-5) 

where  the  value  23. 15  Hz  per  volt  is  the  slope  of  the  linearly  approximated  data  in  Figure 
4-6. 
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Now  that  the  simulated  beacon’s  intensity  and  frequency  have  been  determined, 
the  intensity  must  be  corrected  for  decrease  with  distance  using  Ta,  the  transmission 
factor  for  air.  This  is  given  by 

It~Ta*  Ib  i  (6-6) 

where  Ta  has  the  values  defined  in  Table  5-1. 

At  this  point,  the  intensity  has  been  transmitted  by  the  beacon.  As  a  result  of  the 
intensity  being  received  by  the  detector,  it  is  now  transformed  into  an  A/D  integer 
number  that  represents  the  intensity  received  by  the  set  of  detector  eyes.  Prior  to  running 
the  simulation,  the  user  is  required  to  input  the  maximum  A/D  integer,  ADmax,  that  can  be 
produced  by  the  actual  A/D  converter  as  a  result  of  light  received  from  a  beacon  at  full 
intensity,  with  no  dependence  on  Vb.  The  default  value  for  AD^ax  is  4080.  The 
transformation  is  made  by 

ADo  =  AD^  *  Ib,  (6-7) 

where  ADo  represents  the  highest  possible  A/D  integer  th^  can  be  produced  by  the 
detector  as  a  result  of  light  received  from  a  beacon  whose  intensity  is  dependent  on  Vb. 

As  discussed  in  Chapter  IV,  there  is  a  background  or  noise  intensity  that  is 
received  by  the  detector  in  addition  to  the  intensity  of  the  beacon  itself  This  intensity  is 
applied  in  terms  of  A/D  integer,  so  that  the  full  A/D  intensity  received  by  the  detector  is 

ADtotai  —  ADo  +  ADn,  (6-8) 

where  ADm  is  the  minimum  A/D  integer  produced  by  the  detector.  This  value  is  a  user 
input  parameter,  for  which  the  method  of  measurement  is  described  in  the  next  chapter. 

The  angular  dependence  is  then  applied  to  the  total  A/D  number.  The  equation 
producing  this  dependency  is  given  by 
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ADi  -  ADtotai  *  Te, 


(6-9) 


where  Te'is  given  by 

Te  =  cos  Q,  (6-10) 

where  0  is  the  angle  at  which  the  beacon  light  is  subtended  on  the  active  area  of  the 

photodiode.  This  is  the  lone  factor  on  the  beacon  light  subtended,  due  to  the  negligence 
of  a  lens  effect  as  discussed  in  the  previous  chapter. 

At  this  point,  two  of  the  three  external  factors  affecting  the  received  detector 
intensity  have  been  applied.  The  internal  factors  are  now  applied  to  the  A/D  integer, 

AD],  The  detector  battery  supply,  Vd,  is  affected  in  the  same  manner  as  the  beacon 
oscillator  battery  supply.  The  matrix  shown  in  Table  4-1  is  used  to  select  the  battery  type 
and  loading  condition  as  before.  The  simulation  defaults  are  9  volts  for  battery  type  and 
light  loading.  As  a  result,  the  detector  battery  supply  is  given  by 

Vd  =  VD(t=0)  -  (5.56  X 10^  volts/sec  *  At),  (6-11) 

where  At  is  the  elapsed  scenario  or  detection  system  operation  time. 

Since  one  of  the  two  internal  factors  is  dependent  on  the  detector  supply  voltage, 
and  the  defaults  used  are  for  a  9-volt  battery  under  light  loading  conditions,  the  slope 
given  Equation  6-2  is  used  also  to  compute  the  degraded  voltage.  The  equation  that 
computes  the  detector’s  dependency  on  voltage  supplied  to  the  processor  is  given  by 

AD2  =  ADi  *  Fpi(Vd),  (6-12) 

where  AD2  is  the  yielded  intensity,  which  is  now  dependent  on  the  supply  voltage.  AD2  is 
the  previous  A/D  intensity  from  Equation  6-11  that  would  be  received  if  there  were  no 
voltage  effects  and  Fpj  is  the  relating  transfer  function.  Fpi  is  given  by 

Fpi  =  1.0  -  APout,  (6-15) 
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where  APom  is  the  change  in  processor  output  and  is  calculated  by  multiplying  the 
change  in  detector  supply  voltage  by  the  slope  of  the  linear  region  represented  by  the  data 
in  which  the  source  was  10ft.  from  the  detector,  as  shown  in  Figure  5-6.  The  quantity 
yielded  by  the  transfer  function  tells  the  percentage  of  Ir  remaining  intact  given  the 
reduction  in  detector  supply  voltage.  The  line  slope  is  given  by 

AP 

— —  =  0.0391  volts  ’ .  (6-14) 

The  final  Simbot  internal  detector  factor,  the  processor’s  frequency  response, 
must  now  be  applied  to  the  previously  yielded  A/D  integer.  The  frequency  response  curve 
shown  in  Figure  5-3  shows  how  the  circuit  responds  to  various  input  frequencies.  The 
equation  giving  a  signal  input  to  output  relationship  is  given  by 

AD,=AD,  *Tf(fB,fp).  (6-15) 


In  this  equation,  7/ is  the  Gaussian-like  transfer  function  that  gives  the  desired  frequency 
response  of  the  circuit  and  is  given  by 


where  Afis  given  by 


A/" 

Tf  =exp((-—)), 


(6-16) 


(6-17) 

In  Equation  6-16  and  6-17,  a  is  the  characteristic  width  of  the  frequency  response  curve 
and  fp  is  the  processor’s  tuned  frequency.  The  characteristic  width,  a,  is  set  so  that 
when  Af=0,  the  received  intensity  is  maximum  and  when  Af  is  V2  of  the  desired 
bandwidth,  the  intensity  is  reduced  by  a  factor  of  0.707.  Thus,  o  is  defined  by 
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cr  = 


f tuned 

2*Q’ 


(6-18) 


where /tunerfis  the  frequency  to  which  the  processor  is  tuned. 

The  last  step  in  the  process  of  producing  the  ultimate  A/D  intensity  readings  for 
each  Simbot  eye  is  to  apply  the  effects  of  nose  shadowing  and  discrimination  to  the 
previous  yielded  A/D  reading.  The  function  relating  the  input  intensity  received  by  the 
eyes  to  the  output  intensity  received  by  each  eye  is  given  by 

AD^e  ~  AD3  *  T'sitadow(^>  h  ^miny  Inos  ^  (6-19) 

The  variables  /,  dmin,  and  lm>se  are  illustrated  in  Figure  5-7  and  discussed  in  detail  in 
Chapter  V.  Tshadow  produces  the  ultimate  A/D  intensity  reading  for  each  Simbot  eye.  The 
details  of  the  computations  involved  in  this  transfer  function  are  also  discussed  in 
Chapter  V. 


D.  SUMMARY 

In  summary,  each  of  the  transfer  functions  used  to  generate  the  ultimate  A/D 
intensity  readings  for  each  Simbot  eye  has  been  discussed  again.  The  simulated  beacon 
intensity  and  frequency  are  the  transmission  component  factors  represented  by  transfer 
functions.  The  Simbot  detector  has  both  internal  and  external  factors  that  are  represented 
by  equations  and  transfer  functions.  These  factors  are  the  intensity’s  range  and  angdar 
dependence,  the  effects  of  processor  supply  voltage  on  the  intensity,  the  processor’s 
frequency  response  and  the  effects  of  shadowing  and  eye  discrimination  on  the  intensity. 
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VII.  SOFTWARE  IMPLEMENTATION 


A.  INTRODUCTION 

This  chapter  discusses  how  each  of  the  previously  defined  transfer  functions  are 
implemented  into  the  source  code  for  effective  simulation  of  a  series  of  Simbot  optical 
and  tracking  detection  sequences. 


B.  CODE  DEVELOPMENT 

Keeping  in  mind  the  process  for  utilizing  the  final  A/D  integer  discussed  in  the 
previous  chapter,  the  maximum  A/D  intensity  can  be  processed  by  each  of  the  transfer 
functions  previously  discussed  to  compute  the  final  A/D  reading  for  each  Simbot  “eye”. 
In  addition  to  the  maximum  A/D  intensity,  other  parameters  must  be  known  in  order  to 
use  the  transfer  functions.  To  obtain  these  parameters,  the  user  of  the  model  is  asked  to 
input  a  number  of  values  into  the  program.  Table  7-1  shows  a  list  of  all  the  robot  and 
beacon  parameters  that  the  user  is  asked  to  provide.  Because  each  the  parameters  is 
member  of  the  Simbot  class,  the  user  must  input  the  required  values  prior  to  starting  the 
simulation. 

In  previous  work  done  for  the  simulation,  a  program  was  written  in  the  Java 
programming  language  that  integrated  the  equations  of  motion  for  robot  movement  and 
gave  robot  positional  reports  based  on  commands  issued  to  the  Simbot.  The  same 
program  was  modified  so  that  it  can  be  used  for  the  detection  sequence  simulation.  In  the 
simulation,  the  time  steps  and  subsequent  evolution  of  time  through  the  scenario 


55 


corresponds  to  real  seconds,  so  that  5  seconds  of  Simbot  movement  is  the  same  as  5 
seconds  of  actual  robot  movement.  At  each  of  the  integration  time  steps,  the  range  and 
relative  angle  of  beacon  to  Simbot  is  computed,  along  with  the  total  time  of  Simbot 
operation.  Given  this  information,  the  remainder  of  this  chapter  goes  on  to  describe  how 
the  transfer  functions  are  implemented  in  the  simulation.  The  Java  code  used  for  the 
simulation  is  listed  in  Appendix  A. 

In  the  program,  the  function  compute _pos  integrates  the  equations  of  motion  to 
provide  Simbot  positional  data.  Within  the  function  itself,  at  the  end  of  each  positional 
computation,  the  process  of  “sampling”  the  input  to  the  detector  to  provide  left  and  right 
“eye”  A/D  readings  takes  place.  Before  the  actual  “sampling”  process  can  take  place,  the 
range  and  the  relative  angle  of  the  beacon  to  the  Simbot  is  computed.  The  function 
beac_rel_angle  takes  the  position  of  the  robot  and  the  position  of  the  beacon  and 
computes  relative  angle,  while  the  function  beac  range  takes  the  same  positions  and 
computes  the  range. 

The  sampling  process  is  initiated  by  computing  the  beacon  transfer  function, 
which  consists  of  the  beacon  frequency  and  the  fraction  of  total  beacon  intensity.  The 
function  bcn  xmit  int  uses  the  measured  initial  voltage  of  the  beacon  oscillator  and  the 
time  elapsed  during  the  scenario  to  compute  the  fraction  of  total  intensity  that  the  beacon 
in  capable  of  transmitting.  The  function  compares  the  simulated  beacon  supply  voltage 
to  the  appropriate  region  and  applies  the  corresponding  slope  as  discussed  in  Chapter  VI. 
Equations  6-3  and  6-4  are  used  to  compute  the  intensity  transmitted  by  the  simulated 
beacon. 
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The  beacon  frequency  as  a  function  of  elapsed  time  is  calculated  similarly.  The 
function  hen  Jlsh  Jreq  takes  the  measured,  initial  beacon  supply  voltage;  the  elapsed 


PARAMETER 

NAME 

DEFINITION 

METHOD  OF 
MEASUREMENT 

DEFAULT  VALUE 

MAX_AD_INT 

Integer  value  of 
maximum  A/D  intensity, 
detector  is  capable  of 
receiving 

Place  beacon  directly  in 
front  of  eye  at  closest 
possible  position  record 
value 

4080 

MIN_AD_INT 

Integer  value  of 
minimum  A/D  intensity 
read  when  there  is  100% 
probability  of  detection 

Place  beacon  and  eye  at 
same  hei^t,  maximize 
distance  between  the 
two  until  integer  just 
above  noise  integer  is 
read,  record  value 

48 

MAX_NOISE_INT 

Integer  value  of 
maximum  A/D  reading 
present  when  there  is  no 
beacon  present 

Observe  A/D  readings 
when  beacon  is  off, 
record  maximum  value 

32 

MIN_NOISE_INT 

Integer  value  of 
minimum  A/D  reading 
present  when  no  beacon 
is  present 

Observe  A/D  readings 
when  beacon  is  off, 
record  minimum  value 

16 

MAX_SAT_DIST 

Float  value  of  maximum 
distance  where 
MAX_AD_INT  can  still 
be  read 

place  beacon  and  eye  at 
same  height,  increase 
distance  between  the 
two  until  integer  reading 
falls  just  below 
MAX_AD_INT,  record 
distance  in  feet 

5.0  ft 

MIN_DET_DIST 

Float  value  of  maximum 
distance  where  beacon 
can  still  be  detected, 

100%  prob.  of  detection 

Perform  measurement 
for  MIN_AD_INT, 
record  distance  in  ft. 

20.0  ft 

NOSE_LENGTH 

Float  value  of  height  or 
length  of  nose 

Measure  nose  length  in 
inches 

1.5  inches 

TOT_EYE_SEP 

Float  value  of  total 
distance  between  active 
area  of  the  two  eyes 

Measure  total  distance 
between  inner  extremes 
of  active  eye  area  in  in. 

1  inch 

INrr_BCN_VOLT 

Float  value  of  initial 
batteiy  voltage  for 
beacon  oscillator 

Measure  beacon 
oscillator  battery  voltage 

8.5  volts 

INIT_BCN_VOLT 

Float  value  of  initial 
batteiy  voltage  for 
electrical  circuit 

Measure  electrical 
circuit  battery  voltage 

8.5  volts 

Table  7-1.  Table  of  user  Simbot  input  parameters.  These  parameters  allow  use  of  transfer  functions 
in  the  simulation,  tf  no  value  is  provided,  each  parameter  has  its  own  default  value. 
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scenario  time;  and  the  tuned  beacon  oscillator  frequency  and  computes  the  degraded 
frequency  of  the  beacon  by  using  Equations  6-4  and  6-5. 

The  next  functions  in  the  simulation  compute  the  detector  fractional  values  for  the 
degraded  processor’s  supply  voltage  and  the  circuit’s  frequency  response  factors.  For  the 
detector  circuit  supply  voltage  factor,  the  function  det_spfy_volt  is  used.  Equation  6-1 1  is 
used  to  calculate  the  degraded  processor  voltage. 

The  function  filter  takes  the  tuned  electrical  circuit  frequency,  the  beacon 
frequency,  and  c,  the  characteristic  width  of  the  curve  and  computes  the  fraction  of  total 
intensity  the  detector  is  capable  of  outputting  as  a  result  of  the  difference  between  the  two 
frequencies.  In  effect,  it  determines  the  frequency  response  of  the  circuit.  Equation  6-16, 
which  represents  the  filter  transfer  function,  is  used  to  compute  the  fractional  intensity. 

The  final  function  used  to  calculate  the  A/D  intensity  reading  for  each  “eye”  is 
called  bot  detector.  This  function  is  responsible  for  determining  all  of  the  external 
parameters  affecting  the  intensity  readings.  The  function  itself  determines  if  the  beacon 
falls  within  view  of  the  detector  “eyes”  .  It  uses  the  functions  eye_ang_dep  and 
discriminate  to  determine  the  angular  dependency  of  the  intensity  and  to  discriminate 
between  the  left  and  right  eyes,  respectively.  The  latter  of  these  functions  also  computes 
the  effects  of  shadowing.  The  botjdetector  function  uses  the  parameters  for  range, 
beacon  frequency,  angle  of  incidence,  h,,  Ff,  and  Fpi  to  compute  the  intensity  reading  for 
each  Simbot  “eye”.  As  the  function  is  entered,  the  following  variables  are  declared  and 
initialized. 

int  rcvd_int  =  MIN_NOISE_INT;  //gives  default  value  set  of  eyes 
int  IiEFT_EYE_INT  =  rcvd_int;  //gives  default  value  to  left  eye 
int  RIGHT_EYE_INT  =  rcvd_int;  //gives  default  value  to  right  eye 
boolean  reye_detect  =  false;  //  right  eye,  no  initial  detection 
boolean  leye_detect  =  false;  //  left  eye,  no  initial  detection 
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Because  each  eye  has  a  90°  field  of  view  (FOV),  the  angle  of  incidence  is  compared  to 
the  field  of  view  limits  for  each  eye.  If  the  incident  angle  falls  within  the  FOV  of  either 
eye,  the  boolean  condition  value  initialized  above  is  set  to  true.  When  the  conditional 
value  is  set  to  true  for  either  eye,  a  detection  may  have  occurred  and  as  a  result,  the 
following  series  of  tests  is  initiated. 

First  of  all,  if  the  range  is  greater  than  maximum  detection  distance,  the 
conditional  value  is  set  back  to  false,  the  series  of  steps  is  immediately  ended,  and  both 
the  eye  values  remain  as  initialized.  If  that  condition  is  not  met,  then  the  range  is 
compared  to  the  maximum  saturation  distance  range.  If  the  range  is  less  than  or  equal  to 
MAX_SAT_DIST,  then  the  value  oircvd_int  is  assigned  as 

rcvdjnt  =  lB*Fy*Ff*  MAX_AD_INT  (7-1). 

However,  if  the  range  is  greater  than  MAXJSATJDIST,  then  the  value  of  rcvd_int  is 
assigned  as 

rcvd_int  =  lB*  Fv  *  Ff*  Ta*  MAX  AD_INT  (7-2). 

Once  the  value  of  rcvd  int  is  calculated,  the  function  eye  ang  dep  is  then  used  to 
determine  and  the  angular  dependence  of  the  detector  received  intensity  by  using 
Equation  6-10.  The  value  returned  by  the  function  is  the  angular  dependent  intensity 
received  by  the  set  of  detector  “eyes”. 

In  order  to  compute  the  intensity  readings  for  each  “eye”  a  function  must  be  used 
to  discriminate  the  intensity  values  received  by  the  left  and  right  “eyes”.  The  function 
discriminate  performs  the  necessary  calculations,  by  taking  the  value  of  the  intensity 
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received  by  the  “eye”  set,  the  angle  of  incidence,  and  the  boolean  value  of  either 
leyejdetect  or  reye_detect.  The  function  is  called  twice  and  subsequently  returns  two 
different  values.  This  first  call  is  for  the  left  eye,  returning  the  integer  value  of  the  left 
eye’s  A/D  reading,  while  the  second  call  does  the  same  for  the  right  eye.  The 
discriminate  fiinction  computes  the  values  for  0min  and  0max  defined  by  Equations  5-4  and 
5-5,  respectively.  The  boolean  value  for  either  leyejdetect  or  reyejdetect  is  then  tested. 

If  the  value  is  true,  the  function  returns  and  that  particular  eye  gets  the  same  value  as  the 
intensity  received  by  the  set  of  “eyes”.  If  the  value  is  false,  the  following  three 
conditions  are  tested. 

In  the  first  condition,  if  the  incident  angle  is  less  than  0mi„  the  eye’s  A/D  reading 
is  assigned  the  same  value  as  the  intensity  received  by  the  set  of  “eyes”.  In  the  second 
condition,  if  the  angle  of  incidence  is  greater  than  0max,  the  eye’s  A/D  reading  is  assigned 
MAX  NOISE  INT.  For  the  last  condition,  if  the  angle  of  incidence  lies  between  0min 
and  0max,  the  eye  is  shadowed  to  some  degree  and  is  thus  assigned  the  value  calculated  by 
Equation  6-19,  which  gives  the  intensity  as  a  result  of  nose  shadowing.  The  function 
ends  with  the  computed  A/D  intensity  of  the  eye  being  returned.  As  previously  stated, 
the  fiinction  is  called  twice  to  return  values  for  both  the  left  and  right  eyes. 


C.  SUMMARY 

In  summary,  the  method  of  actually  implementing  the  previously  developed 
transfer  functions  into  the  simulation  code  has  been  discussed.  For  this  implementation, 
an  earlier  Java  program  that  computed  the  Simbot’s  position  based  on  its  equations  of 
motion  was  modified  so  that  at  each  integration  time  step,  the  light  emitted  from  the 
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simulated  beacon  is  “sampled”  by  the  detector,  and  the  resulting  A/D  intensity  reading 
from  the  Simbot’s  “eyes”  is  produced.  The  steps  in  between  the  initial  beacon  emission 
and  the  final  A/D  reading  are  performed  through  use  of  the  transfer  functions  derived  in 
the  previous  sections.  In  the  code,  each  of  the  transfer  functions  is  represented  by  a  Java 
function  that  passes  the  parameters  necessary  for  computing  the  desired  transfer  function 
output,  which  is  returned.  Table  7-2  shows  each  of  the  functions  used  and  its 
corresponding  transfer  function.  The  successful  generation  of  A/D  intensity  reading  for 
each  eye,  now  allows  for  the  data  to  be  used  in  algorithms  for  Simbot  command,  control, 
detection,  and  tracking. 
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FUNCTION 

NAME 

TRANSFER 

FUNCTION 

REPRESENTED 

ARGUMENTS 

PASSED 

OUTPUT 

bcn_xmit_int 

h 

Initial  beacon  battery 
voltage  &  elapsed  time 
in  scenario 

Fraction  of  total 
intensity  detector  is 
capable  of  receiving 
as  a  result  of  decrease 
in  beacon  intensity 

bcn_flsh_freq 

Ff 

Initial  beacon  battery 
voltage,  elapsed  time  in 
scenario  &  tuned 
beacon  frequency 

Degraded  beacon 
frequency  as  a  result 
of  time 

det_sply_volt 

Vd 

Initial  beacon  battery 
voltage  &  elapsed  time 
in  scenario 

Fraction  of  intensity 
detector  is  capable  of 
receiving  as  a  result 
of  its  degradation  is 
supply  voltage 

filter 

Tf 

Tuned  detector 
frequency,  current 
beacon  freq.  & 
characteristic  width  of 
frequency  response 
curve 

Fraction  of  intensity 
detector  is  capable  of 
receiving  as  a  result 
of  its  frequency 
response 

bot_detector 

none 

Detector  range  from 
beacon,  current  beacon 
frequency,  T/i  Tb,  &Fv 

A/D  intensity  reading 
for  each  eye 

eye_ang_dep 

Te 

On-axis  received 
intensity  for  set  of  eyes 

Angular  dependent 
intensity  for  eye  set 

discriminate 

Tshadow 

\ 

Angle  of  incidence,  off- 
axis  intensity  for  eye  set 
&  true/false  condition 
confirming  detection 
for  individual  eye 

Received  intensity 
for  individual  eye  as 
a  result  of  shadowing 
after  discrimination 
between  eyes 

Table  7-2.  Table  showing  each  of  the  Java  functions  used  to  represent  the  derived  signal  input  to 
output  transfer  functions.  The  combined  set  of  these  functions  allows  for  generation  of  A/D  intensity 
readings  for  each  eye. 
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VIII.  SIMULATION  PERFORMANCE  VERFICATION 


A.  INTRODUCTION 

This  chapter  describes  how  each  of  the  transfer  functions  implemented  for  the 
effective  simulation  of  the  SE  3015  robot  optical  detection  system  and  sequence  were 
verified  for  accurate  behavior  and  performance. 


B.  PERFORMANCE  TESTS 

As  previously  stated,  the  purpose  of  this  thesis  is  to  develop  a  simulation  that 
accurately  and  effectively  replicates  the  behavior  of  the  present  optical  detection  system 
used  on  robots  for  the  SE  301 5  Robot  Wars  Competition.  In  order  to  analyze 
performance,  a  series  of  tests  was  conducted  on  each  of  the  program  functions  listed  in 
Table  7-2.  To  conduct  these  tests,  two  scenarios  were  developed  for  the  Simbot  to 
operate  in.  In  the  first  test,  the  Simbot  was  given  a  set  of  commands  from  a  scripted 
scenario  and  a  simulated  beacon  was  placed  at  various  stationary  distances  away  from  the 
Simbot’ s  initial  position.  The  total  time  of  the  scenario  was  39  seconds.  In  the  second, 
the  Simbot  and  simulated  beacon  were  placed  in  fixed  positions  so  that  the  distance 
between  the  Simbot  and  beacon  was  greater  than  the  maximum  saturation  distance  and 
less  than  the  maximum  detection  distance.  The  values  of  the  robot  input  parameters 
listed  in  Table  6-1  were  varied  and  the  resulting  Simbot  generated  A/D  data  analyzed  and 
compared  to  expected  results.  The  tests  cpnducted  may  also  be  compared  to  some  of  the 
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experiments  conducted  in  determining  the  pertinent  features  of  the  detector  and 
transmitter  needed  for  effective  modeling. 

First  of  all  the  hcn_xmit_int  function  was  tested  for  effectiveness.  This  test 
entailed  simulating  the  “the  turning  on  and  off  of  the  beacon”  using  the  scripted  scenario 
and  a  check  to  ensure  that  the  intensity  of  the  beacon  was  decreasing  with  time  due  to 
battery  drainage  using  the  fixed  position  scenario.  The  first  test  was  accomplished  by 
simply  changing  the  value  of  the  input  parameter  for  the  initial  beacon  battery  voltage, 
BCN_SPLY_VOLT.  When  the  value  was  initially  at  its  nominal  value  of  8.5  volts,  the 
Simbot  behaved  normally.  As  expected,  the  data  revealed  no  noticeable  decrease  in 
intensity  over  this  short  operation  period.  When  the  input  value  was  decreased  to  its 
minimum  of  1.5  volts,  the  simulated  beacon  behaved  as  if  it  was  “off’.  As  the  Simbot 
moved  through  the  scenario,  it’s  A/D  readings  remained  at  the  minimum  noise  level  of  16 
as  expected.  The  degradation  of  the  simulated  beacon’s  intensity  with  time  was  checked 
by  simply  observing  the  value  of  the  beacon’s  normalized  intensity,  at  each  time  step,  as 
the  scenario  progressed.  As  expected,  the  value  decreased  with  progressing  scenario 
time. 

The  functions  ben Jlsh Jreq  and  filter  were  tested  simultaneously  using  the  fixed 
position  scenario  because  each  one’s  unique  dependency  on  the  other.  When  the  beacon 
is  tuned  to  any  frequency  other  than  the  fi-equency  to  which  the  electrical  circuit  is  tuned, 
there  is  expected  to  be  a  decrease  in  the  frequency  response  of  the  detector  filter.  This 
decrease  in  frequency  response  results  in  a  decrease  in  the  Simbot’ s  A/D  readings.  To 
test  these  expected  results  the  input  parameter  for  the  tuned  beacon  frequency  was  varied 
to  two  different  values.  The  first  value  was  the  exact  same  frequency  as  that  to  which  the 
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detector  was  tuned.  As  expected,  the  Simbot’s  A/D  readings  corresponded  to  their 
maximum  possible  values  given  other  dependencies  such  as  source  range  and  incident 
angle.  The  second  value  used  was  the  lower  bandwidth  of  the  frequency  response  curve, 
/i,  given  the  assigned  beacon  frequency  and  a  0  of  50.  As  expected,  when  the  same  test 
was  conducted  as  before  the,  Simbot’s  A/D  readings  were  initially  reduced  from  their 
maximum  values  by  a  factor  of  0.707.  The  simulated  beacon’s  frequency  degradation 
with  voltage  and  time  was  measured  by  simply  observing  that  the  frequency  did  indeed 
decrease  with  progressing  scenario  time.  The  result  of  this  decrease  in  simulated  beacon 
frequency  also  affected  the  frequency  response  of  the  detector  and  the  resulting  Simbot’s 
A/D  readings. 

The  program  function  det  sply  volt  was  tested  by  simply  observing  the  decrease 
in  Simbot  detector  supply  voltage  with  progressing  scenario  time  using  the  fixed  position 
scenario.  Because  the  actual  A/D  readings  only  decreased  slightly  due  to  the  relatively 
short  scenario  time,  the  actual  value  of  the  transfer  function  represented  by  detjsply  volt, 
Vd,  was  observed  to  ensure  that  it  decreased  as  expected.  The  results  of  the  test  were 
conclusive  and  agreed  with  the  expected  results. 

The  hotjdetector  function  contains  the  ^e_ang_dep  and  the  discriminate 
functions.  The  function  itself  uses  the  distance  between  the  Simbot  and  beacon  and  the 
angle  at  which  the  beacon  light  is  incident  on  the  Simbot  “eyes”  to  determine  whether  the 
Simbot  will  be  capable  of  generating  A/D  data.  If  the  determination  is  made  that  A/D 
data  can  be  generated  by  the  Simbot’s  detector,  the  eyejangjdep  and  discriminate 
functions  are  used  to  determine  the  intensity’s  angular  dependence  and  the  effects  of  nose 
shadowing,  respectively.  These  functions  were  tested  using  the  scripted  scenario.  The 
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simulated  beacon  was  placed  at  a  position  representing  the  middle  of  the  Robot  Wars 
Competition  playing  field  and  the  Simbot  positioned  at  one  of  the  playing  field  comers. 
Figure  8-1  shows  the  positional  setup  used  to  test  the  bot  detector  function.  The  script 
gave  the  Simbot  commands,  which  positioned  it  at  various  relative  angles  and  distances 
from  the  simulated  beacon.  The  observed  data  consisted  of  the  range  of  the  Simbot  from 
the  beacon,  the  angle  at  which  the  beacon  light  was  incident  on  the  Simbot  detector’s 
“eyes”,  and  the  resulting  A/D  intensity  reading  for  each  Simbot  “eye”.  As  the  Simbot 
made  its  approach  toward  the  simulated  beacon  the  left  eyes’  A/D  value  remained  at  the 
minimum  noise  level,  while  the  right  eyes’  A/D  value  increased  as  the  Simbot  got  closer 
to  the  beacon.  As  the  Simbot  passed  the  beacon,  both  A/D  values  fluctuated 
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Figure  8-1.  Simbot  performance  test  setup. 
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between  the  minimum  and  maximum  intensity  noise  levels.  As  the  Simbot  spun  on  its 
own  axis  (both  wheels  at  same  angular  velocity,  in  opposite  directions),  the  values  of 
each  eyes’  A/D  reading  was  observed,  to  check  the  effects  of  the  shadowing  function. 

The  observation  revealed  that  the  value  for  a  completely  shadowed  eye  would  slightly 
increase  as  that  eye  came  closer  to  being  in  a  head-on  position  with  the  beacon;  and  that 
the  value  for  the  eye  which  had  been  in  a  head-on  position  would  start  to  decrease  as  the 
Simbot  turned  away  from  the  beacon.  The  A/D  readings  for  both  “eyes”  were  observed 
during  the  entire  Simbot  scenario.  The  entire  series  of  A/D  readings  did  indeed  match  the 
positional  and  rotational  locations  of  the  Simbot  in  each  instance. 

C.  CONCLUSIONS 

In  order  to  test  the  defined  transfer  functions  for  effectiveness  in  simulating  robot 
behavior,  each  of  their  corresponding  Java  code  functions  were  tested.  The  program 
functions  were  tested  by  using  a  Simbot  in  two  separate  scenarios.  Each  of  the  transfer 
function  values  and  the  resulting  A/D  data  from  each  Simbot  “eye”  were  observed  while 
the  Simbot  completed  its  given  scenario.  In  addition  to  performing  these  tests,  during  the 
development  of  each  program  function,  the  Simbot  was  given  various  other  simple  tests 
and  scenarios,  which  gave  ample  indication  of  accurate  Simbot  A/D  data.  From  the 
series  of  tests  conducted  on  the  Simbot  and  analysis  of  the  resulting  A/D  data,  the 
conclusion  may  be  dravm  that  the  quantitative  simulation  is  effective  in  replicating  the 
performance  of  the  actual  SE  3015  robot. 
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D.  SUMMARY 


This  chapter  described  how  each  of  the  defined  transfer  functions  for  simulating 
the  SE  3015  robot  optical  detection  system  and  detection  sequence  were  verified  to 
ensure  accurate  behavior  and  performance. 
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IX.  SIMULATION  OPERATION 


A.  INTRODUCTION 

This  chapter  describes  how  the  total  SE  3015  Robot  simulation  operates.  In 
addition  the  simulation  architecture  is  given  along  with  the  functionality  of  each  of  the 
simulation  components. 


B.  OVERVIEW 

The  purpose  of  the  simulation  is  to  provide  students  with  a  tool  that  allows  them 
to  design  SE  3015  robot  detection  parameters  and  to  evaluate  the  effectiveness  of  these 
parameters  as  well  as  robot  tactics  and  behavior  through  use  of  a  graphical  model  that 
replicates  the  interactions  that  take  place  between  a  robot  and  its  target.  The  simulation 
manipulates  two  robot  objects  (Simbots).  The  first  Simbot  is  given  a  program  function 
that  simulates  the  detection  algorithm  used  with  an  actual  robot.  The  second  Simbot  is 
given  a  scripted  scenario  by  which  its  movement  is  based,  so  as  to  act  as  a  target  for  the 
first  Simbot.  All  of  the  positional  data  for  each  of  the  Simbots  is  directed  by  the 
simulation  to  output  position  interpolator  files.  The  graphics  program  uses  the  position 
interpolator  files  to  recreate  each  of  the  Simbot’ s  movements,  thus  replicating  the 
detection  sequence  with  a  3-dimensional  animation  display.  It  should  also  be  noted  that 
it  is  possible  the  run  the  simulation  in  a  mode  where  neither  of  the  Simbot's  is  scripted  so 

As  to  emulate  the  acutal  Robot  Wars  competition.  Figure  9-1  is  an  illustration  of  the 
Simulation  architecture.  A  flow  chart  of  the  simulation  processes  is  shown  in  Figure  9-2. 
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The  total  simulation  consists  of  a  primary  program  that  computes  each  of  the 
Simbot’s  positions,  Simbot  positional  and  orientation  interpolator  files,  and  a  graphics 
program  that  generates  the  animation  display.  The  primary  program  is  written  in  Java 
and  uses  two  Simbot  objects,  as  previously  discussed.  The  detection  algorithm  written  in 
Dynamic  C  for  the  SE  3015  Robot  Wars  was  converted  into  a  Java  function  that 
replicates  its  logic  and  gives  the  Simbot  the  same  behavior  as  the  actual  robot.  The 
Simbot  position  interpolator  files  generated  by  the  primary  program  are  ASCII  text  files. 
The  secondary  program  is  the  graphics  program  used  to  animate  the  Simbots,  which  was 
written  in  VRML  (Virtual  Reality  Modeling  Language).  This  VRML  program  uses  the 
interpolator  files  to  generate  an  animated  replication  of  the  SE  3015  Robot  Wars  playing- 
field  and  a  Simbot  engaged  in  a  detection  and  targeting  sequence  with  another  Simbot. 
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C.  SIMULATION  COMPONENTS 


1.  Primary  Program 

As  previously  stated,  the  primary  program  is  written  in  Java.  The  Java  code 
instantiates  two  Simbot  objects  and  subsequently  computes  the  position  and  heading  of 
each  Simbot.  A  detection  and  targeting  algorithm  written  in  Dynamic  C  is  converted  to  a 
Java  function  called  run_program.  This  function  gives  the  first  Simbot  the  same  logical 
behavior  as  its  actual  robot  counterpart  and  is  used  to  determine  the  next  movement 
command  given  to  the  Simbot.  The  modifications  to  the  Dynamic  C  detection  algorithm 
required  for  use  in  the  simulation  shall  be  discussed  later  in  this  chapter.  A  script  is  made 
out  for  the  second  Simbot.  This  script  simply  contains  Simbot  commands  that  allow  the 
Simbot  to  behave  in  some  preconceived  manner,  in  terms  of  position  and 
heading,  to  be  determined  by  the  user.  The  method  for  developing  a  Simbot  script  shall 
also  be  discussed  later  in  this  chapter. 

For  the  primary  Java  program,  a  previously  written  program  that  computes  the 
equations  of  motion  for  one  Simbot  based  on  commands  given  in  a  Simbot  script  and 
produces  the  resulting  positional  and  heading  output  was  modified.  The  modifications 
first  of  all,  allow  two  Simbots  to  be  instantiated  and  secondly,  implement  the  physics  and 
components  needed  for  an  optical  detection  system  and  a  detection  and  tracking 
algorithm  for  one  of  the  Simbots.  During  each  of  the  time  steps  for  computing  the  first 
Simbot’ s  position,  its  detector  attempts  to  sample  the  beacon  light  from  the  second 
Simbot.  A  resulting  A/D  intensity  reading  for  each  of  its  eyes  is  yielded.  The  readings 
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for  each  eye  are  then  used  by  the  run  program  function  to  generate  the  next  movement 
command  that  will  be  issued  to  the  Simbot. 

This  process  goes  on  until  the  total  scenario  time  is  reached.  For  the  scenario 
time,  each  simulation  and  scenario  second  correlates  to  an  actual  second.  Time  steps  for 
the  equations  of  motion  are  0.01  seconds,  the  Simbot  executes  each  command  issued  to 
the  Simbot  for  a  duration  of  0. 1  seconds,  and  at  every  0.5  second  interval  the  positional 
and  heading  data  for  each  Simbot  is  output  to  positional  and  angular  interpolator  data 
files  that  are  used  by  the  VRML  software  to  generate  the  animation  scene.  The  Java 
source  code  is  listed  in  Appendix  A. 

2.  Graphics  Program 

The  VRML  program  is  used  to  generate  the  3-dimensional  (3D)  graphics  scene  of 
the  Simbots  and  Robot  Wars  playing-field  for  the  simulation.  The  program  uses 
primitive  VRML  nodes  to  generate  a  fairly  accurate  depiction  of  each  of  the  objects  with 
which  the  simulation  is  concerned.  The  contents  of  the  interpolator  data  files  generated 
by  the  Java  program  are  “copied  and  pasted”  into  the  VRML  program  and  used  to 
animate  each  Simbot’ s  movement  with  respect  to  position  and  heading  on  the  Simbot 
playing-field.  Samples  of  the  interpolator  output  files  are  listed  in  Appendix  B.  The 
VRML  source  code  is  listed  in  Appendix  C. 

3.  Dynamic  C  Detection  Algorithm  Conversion  and  Implementation 

The  primary  program’s  Java  function,  run_program  contains  a  modified  version 
of  the  user’s.  Dynamic  C  written,  robot  detection  and  tracking  code.  The  remainder  of 
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this  section  discusses  how  the  Dynamic  C  code  is  converted  to  the  nin  program 
function  and  how  the  algorithm  is  implemented  within  the  primary  program. 

Each  SE  3015  robot  is  equipped  with  two,  dual-drive  servo  motors.  Each  motor  is 
capable  of  operating  at  15  different  speeds,  in  both  the  forward  and  reverse  modes.  The 
Dynamic  C  programming  language  is  the  language  in  which  the  robot  communicates. 

The  language’s  platform  function  accepts  robot  commands  and  issues  them  to  the  robot 
for  action.  The  robot  command  is  issued  as  an  eight  character  motor  control  string,  in  the 
Dynamic  C  function  strcpy,  that  follows  the  format  specified  in  [Jones,  1997].  An 
example  command  string  is 

“ffgrffgr”. 

In  this  string  the  first  four  characters  represent  left  robot  wheel  commands  and  the  last 
four  characters  represent  right  robot  wheel  commands.  A  further  breakdown  of  the  motor 
control  string  is  provided  in  Table  9-1. 

For  the  simulation,  the  platform  and  strcpy  functions  are  replaced  by  a 
compute_pos  fimction  that  takes  the  Simbot  commands  and  computes  the  resulting 
Simbot  position.  Because  the  3^^  string  byte  (motor  status)  is  somewhat  a  duplication  of 
the  1**  byte  (wheel  speed)  and  the  fourth  byte  (wheel  distance  counter)  is  not  used,  the 
compute_pos  function  only  takes  two  values,  the  1**  and  5*  string  values  in  decimal 
format.  The  forward  or  reverse  byte  is  incorporated  into  these  bytes  through  used  of  a 
sign  for  magnitude,  so  that  a  negative  sign  would  indicate  a  reverse  command.  As  a 
result  of  these  modifications,  the  “ffgrffgr”  command  would  be  issued  to  the  Simbot  in 
the  simulation  as 

compute_pos(15,lS)> 
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Motor  Control  String 

Robot  receives  a  motor  control  string  to  control  its  direction  and  speed.  The  string 
is  8  bytes  long  and  is  broken  down  as  listed  below.  For  example,  control  string 
“fFgrfFgr”  issues  a  command  for  both  motors  to  go,  rotate,  forward  at  speed  15. 

ffgrffgr 

1**  byte  left  wheel  speed  (hexadecimal  values  0-f  corresponding  to  0-15) 

2“^  byte  left  motor  direction  (f  =  forward,  r  =  reverse) 

3'^'*  bj1;e  left  motor  status  (g  =  go,  s  =  stop) 

4*  byte  left  wheel  distance  counter  (generally  not  used) 

5*  byte  right  wheel  speed  (hexadecimal  values  0-f  corresponding  to  0-15) 

6th  b54e  right  motor  direction  (f  =  forward,  r  =  reverse) 

7th  byte  right  motor  status  (g  =  go,  s  =  stop) 

8*'’  byte  right  wheel  distance  counter  (generally  not  used) 


The  robot  code  sends  this  to  an  internal  motor  function  by  use  of  a  string  copy 
fimction  to  a  buffer  string  via  the  platform  function.  The  motor  function  breaks 
down  the  string  as  listed  above  and  sends  the  direction  and  speed  information  to  the 
left  and  right  motors  which  will  then  turn  the  robot  wheels.  The  functionality  can 
occur  any  place  in  the  robot  program  and  as  often  as  needed. 


Table  9-1.  Motor  control  string  format,  [Jones,  1997]. 


In  Dynamic  C,  the  ad_rd8  function  samples  the  A/D  intensity  reading  received 
by  each  robot  eye  and  returns  the  resulting  value.  As  stated  previously,  in  the  simulation 
the  simulated  target  beacon  from  the  second  Simbot  is  sampled  at  each  integration  time 
step.  The  run_program  function  takes  these  two  integer  values  as  an  input  and  uses  the 
Dynamic  C  robot  detection  and  tracking  algorithm  logic  to  issue  the  Simbot  its  next 
command.  While  “for  loops”  are  used  in  the  Dynamic  C  code  to  extend  the  amount  of 
time  a  robot  executes  a  given  command,  they  may  also  be  used  within  the  run_program 
function.  The  ultimate  fimction  of  the  run_program  method  is  to  accurately  replicate 
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and  implement  the  exact  logic  used  in  the  Dynamic  C  algorithm,  using  Java  code  that  is 
much  easier  to  understand  and  comprehend  than  its  Dynamic  C  counterpart.  Appendix  D 
shows  a  sample  of  Dynamic  C  robot  detection  and  tracking  logic.  Appendix  E  shows  its 
Java  Simbot  counterpart. 

4.  Simbot  Script 

The  script  from  which  the  second  Simbot’ s  commands  are  taken  is  simply 
composed  of  a  series  of  compute_pos  functions  that  enable  that  Simbot  to  move  in  a 
distinct  pattern  to  be  predetermined  by  the  user.  An  example  of  a  simple  pattern  would 
be,  if  the  user  wanted  the  Simbot  to  move  out  straight  for  5  seconds  and  then  come  back. 
This  set  of  movements  or  pattern  is  simply  defined  by  outlining  the  list  of  commands  that 
allow  the  robot  to  execute  the  pattern.  An  example  Simbot  script  is  shown  in  Appendix 
F. 

D.  SUMMARY 

In  summary,  the  actual  Simbot  simulation  and  is  components  have  been 
discussed.  The  simulation  is  composed  of  a  primary  and  secondary  program.  The 
primary  program  is  the  Java  code  that  instantiates  two  Simbots  and  their  beacons  and 
computes  their  positional  and  rotational  status  during  a  detection  and  tracking  sequence. 
This  Java  code  also  implements  the  physics  and  components  of  an  optical  detection 
system,  to  include  its  Dynamic  C  detection  algorithm,  for  one  of  the  Simbots.  The 
positional  and  rotational  data  computed  is  output  to  positional  and  angular  interpolator 
data  files.  The  secondary  program  consists  of  code  written  in  VRML  that  is  “cut  and 
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pasted  ”  into  the  interpolator  data  files  and  used  to  generate  a  3 -dimensional  animation  of 
a  simulated  Robot  Wars  detection  and  tracking  sequence  between  two  Simbots. 
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X.  CONCLUSIONS  AND  FUTURE  WORK 


A.  CONCLUSION 

One  of  the  primary  purposes  for  the  SE  3015  Robot  Wars  simulation  project  is  to 
evaluate  the  use  and  effectiveness  of  modeling  and  simulation  as  an  aid  to  the  overall 
systems  engineering  process.  During  the  SE  3015  course,  over  50%  of  each  student’s 
time  is  consumed  designing  and  testing  the  robot’s  optical  detection  system.  The  detailed 
model  of  that  system,  discussed  and  implemented  in  this  thesis,  will  provide  students 
with  the  ability  to  test  and  evaluate  both  perspective  and  actual  robot  detection  and 
tracking  parameters  in  a  synthetic  environment,  either  alone  or  against  a  user  controlled 
Simbot. 

The  simulation  provides  its  user  with  fairly  accurate  graphical  depiction  of  an 
actual  SE  3015  robot  and  includes  the  physics  apd  logic  necessary  for  accurate  robot 
movement,  detection,  and  response  to  an  external  stimulus.  The  simulation  is  capable  of 
integrating  the  following  features:  implementation  of  actual  Dynamic  C  detection  and 
tracking  code;  realistic  optical  detection  system  parameters,  performance,  and  behavior; 
replicated  real-time  visualization;  accurate  robot  movements. 

A  previously  written  Java  program  by  the  author  that  computes  the  actual  robot 
motion  equations  for  one  Simbot  serves  as  the  foundation  for  this  simulation.  The 
program  includes  measured  and  calibrated  robot  wheel  angular  velocities,  wheel 
diameters,  and  placeholders  for  acceleration  and  deceleration  values.  That  program  was 
modified  so  that  two  Simbots  are  instantiated  and  “endowed”  with  optical  detection 
systems  for  acquisition  and  detection.  User  input  parameters  define  the  limits  and 
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capabilities  of  the  simulated  detection  system.  A  transfer  function  approach  is  used  to 
replicate  the  series  of  processes  between  the  initial  beacon  light  emission  and  the  final 
conversion  of  binocular  reception  of  that  signal  to  A/D  integer  numbers  representing  the 
light’s  received  intensities.  The  final  A/D  numbers  generated  by  each  Simbot  detector 
eye  is  then  used  in  conjunction  with  a  modified,  but  simplified  version  of  the  actual 
Dynamic  C  detection  and  tracking  algorithm  to  control  the  Simbots’  movements.  The 
Java  program  outputs  Simbot  positional  and  rotational  data  to  interpolator  files  that  a 
Java  program  uses  to  generate  a  3-dimensional  animated  scene  replicating  the  Robot 
Wars  competition. 

Since  the  primary  objective  of  this  thesis  is  to  accurately  simulate  the  robot’s 
optical  detection  system,  several  performance  tests  were  conducted  to  measure  the 
effectiveness  of  each  simulated  component  in  the  system.  The  tests  revealed  that  given  a 
set  of  input  parameters,  the  simulation  was  indeed  effective  in  replicating  the  robot’s 
optical  detection  system  functionality.  The  significant  component  transfer  functions  have 
been  implemented  and  placeholders  are  included  for  all  other  components.  The 
implementation  is  completely  modular  so  that  transfer  functions  be  easily  altered  in 
future  simulations.  The  simulation  is  able  to  identify  and  replicate  flaws  in  the  original 
Dynamic  C  detection  algorithm,  mistuned  (fi-equency)  beacons  and  processors,  low 
beacon  battery  supplies,  and  low  processor  battery  supplies.  The  vital  components  of  the 
detection  system  that  were  tested  were  the  battery  drainage  of  the  beacon  and  processors, 
processor  frequency  response  and  the  effects  of  nose  discrimination  and  shading.  Due  to 
the  fact  that  actual  current  supply  measurements  were  not  conducted,  battery  drainage 
behavior  may  not  be  realistic.  Because  of  this  and  the  fact  that  future  robots  may  have 
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different  battery/load  characteristics,  a  battery  loading  matrix  has  been  included  in  the 
simulation  which  can  be  easily  used  to  input  actual  parameters.  Tests  have  shown  the 
simulation  to  be  effective  in  providing  an  accurate  depiction  of  how  an  actual  robot 
behaves  and  performs. 

In  summary,  the  simulation  implements  the  required  physics  for  each  of  the 
pertinent  components  of  the  optical  detection  system.  The  overall  simulation  uses  an 
object-oriented  approach  to  model  the  behavior  of  two  SE  3015  robots  engaged  in  a 
series  of  detection,  tracking,  and  attacking  sequences.  A  3-dimensional  animation  scene 
allows  the  user  to  visualize  the  behavior  and  motion  of  the  two  Simbots  on  a  synthetic 
playing-field.  The  integrity,  logic,  and  overall  functionality  of  the  Dynamic  C  detection 
algorithm  and  optical  detection  system  have  been  preserved.  As  a  result  of  these 
accomplishments,  the  goals  and  objective  of  this  thesis  and  simulation  have  been  met. 


B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

Future  work  directly  applicable  to  the  optical  detection  system  should  include 
analysis  and  measurements  of  the  currents  supplied  and  various  loading  conditions  for  the 
Simbot  processors.  Verification  and  validation  (V  &  V)  of  the  simulated  detection 
system  with  an  actual  robot  is  needed.  V  &  V  should  include  comparison  of  actual  and 
simulated  robot  combat. 

Future  work  on  the  Robot  Wars  simulation  project  should  include  improved 
physics  for  the  various  robot  weapon  systems  and  the  drive  train,  implementation  of 
various  robot  weapon  systems  to  include  the  required  physics  for  each.  Most  of  the 
recommendation’s  in  [Jones,  1997]  are  still  important  areas  for  continued  work. 
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Some  of  the  computer  science  related  issues  that  must  be  addressed  are  the 
incorporation  of  a  user-friendly  Graphical  User  Interface  (GUI)  that  allows  the  user  to 
input  robot  parameters  and  interact  with  the  simulation  more  easily.  Furthermore,  while 
in  its  present  state,  the  simulation  is  capable  of  being  accessed  by  anyone  having  an 
Internet  connection  and  the  appropriate  VRML  browser,  its  use  of  Java  and  VRML  lays 
the  foundation  for  the  simulation  to  be  fully  networked.  Appendix  F  describes  how  the 
simulation  is  set  up  and  Appendix  G  describes  how  it  may  be  accessed  online. 
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APPENDIX  A:  JAVA  SOURCE  CODE 


The  simulation  uses  the  code  contained  within  Simbotjava  to  simulate  a  series  of 
repetitive  detection  and  tracking  sequences  between  two  SE  3015  robots.  Angular 
velocites  for  each  of  the  robot  wheel  speeds,  wheel  diameters,  and 
acceleration/deceleration  values  are  read  in  from  the  text  file  robot.con.  The  remainder 
of  this  appendix  lists  the  source  code,  Simbotjava  and  the  text  file  robotcon. 
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//  File:  Simbot.java 

//  Author:  LT  Wm.  Ben  McNeal 

//  Robot  Wars  Simulation  Primary  Program 

//  Operating  Environment:  Windows  NT,  Windows  ‘95/’97,  IRIX  6* 

I  I  Compiler:  JDK  Version  1.1.3 

//  Description:  This  program  simulates  the  movement  of  two  Simbots  engaged  in 
a  series  of  detection  and  tracking  sequences 
//Inputs:  See  Table  6-1 
//Outputs:  None 

//  Last  compile/run  date:  18  December  1997 
//Warnings:  None 


import  java.io.*; 
import  java. util.*; 

/ / import  vrml . * ; 

//import  vrml. field. *; 

//import  vrml. node.*; 

public  class  Simbot 

{ 

private  static  int  EOF  =0; 

private  static  boolean  TRACE  =  false; 

private  static  boolean  posOpen  =  false; 

public  static  int  pc  =  0;  //print  counter  so  that  at  every  .5 

//secs  output  is  printed  to  file  and 
/ /screen 

float  robotX  =  15. 5f,  robotZ  =  15.5f,robotY  =  0.425f; 
public  float  robotTheta  =  ( float) Math. PI; 

float  beacX  =9. Of,  beacZ  =  9. Of;  //in  feet 

private  float  bot_radius  =  .53125f;  //in  feet 

private  float  asgn_beac_freq  =  16490f; 

private  float  beac_freq  =  asgn_beac  freq; 

private  float  filter_q  =  100. Of;  ~ 

private  float  x  =  beac_freq  /  (2. Of  *  filter_q) ; 

private  float  sigma  =  (float) (Math. sqrt ( (double) (x*x) /. 6931) ) ; 

private  float  MAX_SAT_DIST  =  5. Of; 
private  float  MAX_DET_DIST  =  20. Of; 
private  int  MAX_AD_INT  =  4080; 
private  int  MIN_DET_INT  =48; 
private  int  MAX_NOISE_INT  =  32; 
private  int  MIN_NOISE_INT  =  16; 
private  int  Right_AD,  Left_AD; 

private  float  NOSE_LENGTH  =  1.5f; 
private  float  EYE_LENGTH  =  .344f; 
private  float  TOT_EYE_SEP  =  0.5f; 

private  float  INIT_BCN_VOLT  =  8.5f; 
private  float  INIT_EC_VOLT  =  9.0f; 

private  int  timeStep  =  100;  //  number  of  steps  PER  SECOND 

private  float  wheel  base. 
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left_wheel_diam, 

right__wheel_diam; 

public  float  [] []  speed_array;  //  16  speeds  for  LEFT  and  RIGHT 

wheels 

private  float  vel; 

private  float  accelDelta^ 
drivenDecelDelta  ^ 

f reeDecelDelta;  //  constants  for  acceleration  and 

deceleration 

private  static  int  leftspeed,  rightspeed; 
private  static  float  duration  =  O.lf; 
private  static  float  time  =  O.Of; 
private  static  float  SCENE_TIME  =  10. Of; 
private  float  numsteps,  key; 

private  float  rpsl^  rps2;  //  rps  -  revolution  per  second 

private  float  rpsorderl^  rpsorder2; 

private  float  rpschangel,  rpschange2; 

private  float  transientStepsl,  transientSteps2; 

private  float  deltal,  delta2; 

private  PrintWriter  ps_pos,  ps_time,  ps_angle,  ps_key; 
private  int  i,j,k; 

public  Simbot ( ) 

{ 

Float  fltobj  =  new  Float (0.0); 

try 

{ 

BufferedReader  in  -  new  Buf feredReader (new 
FileReader ( "Robot . con" ) ) ; 

in . readLine ( ) ; 
in. readLine ( ) ; 

String  line  =  in. readLine () ; 

StringTokenizer  t  =  new  StringTokenizer (line,  "  \n\t\r"); 
Float  a  ,=  fltobj . valueOf ( t . nextToken ( ) ) ; 
accelDelta  =  a. floatValue ( ) ; 

if  (TRACE) 

System. out .println ("accelDelta  =  "  +  accelDelta) ; 

in. readLine ( ) ; 
line  =  in. readLine 0  ; 

t  =  new  StringTokenizer (line,  "  \n\t\r") ; 
a  =  fltobj .valueOf (t.nextTokenO ) ; 
drivenDecelDelta  =  a . floatValue () ; 
if  (TRACE) 

System. out.println( "drivenDecelDelta  ="  +  drivenDecelDelta); 

in. readLine ( ) ; 
line  =  in . readLine ( ) ; 

t  =  new  StringTokenizer (line,  "  \n\t\r") ; 
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a  =  fltobj , valueOf (t .nextToken ( ) ) ; 
freeDecelDelta  =  a . floatValue  ( ) ; 
if  (TRACE) 

System. out. println ("freeDecelDelta  ="  +  freeDecelDelta); 

in. readLine ( ) ; 
line  =  in. readLine 0 ; 

t  =  new  StringTokenizer (line^  "  \n\t\r"); 
a  =  fltobj .valueOf (t .nextToken 0) ; 
left_wheel__diam  =  a .  floatValue  ()  ; 
if  (TRACE) 

System. out. println("left_wheel_diam  ="  +  left_wheel_diam) ; 

a  =  fltobj .valueOf (t.nextTokenO ) ; 
right_wheel_diam  =  a. floatValue () ; 
if  (TRACE) 

System. out. println  ("right__wheel_diam  ="  +  right_wheel_diam) 

in. readLine ( ) ; 
line  =  in. readLine 0 ; 

t  =  new  StringTokenizer (line,  "  \n\t\r") ; 
a  =  fltobj , valueOf (t. nextToken 0) ; 
wheel_base  =  a. floatValue () ; 
if  (TRACE) 

System,  out. println ("wheel_base  ="  +  wheel_base) ; 

in. readLine ( ) ; 

line  =  in. readLine 0 ; 

speed_array  =  new  float[16] [2]; 

for  (int  speed_num  =  1;  speed_num  <=  15;  speed_num++)  { 
t  =  new  StringTokenizer (line,  "  \n\t\r") ; 
a  =  fltobj .valueOf (t. nextToken 0) ; 
vel  =  a , floatValue ( ) ; 
speed_array [speed_num] [0]  =  vel; 
a  =  fltobj .valueOf (t.nextTokenO ) ; 
vel  =  a . floatValue ( ) ; 
speed_array [speed_num] [1]  =  vel; 
in . readLine ( ) ; 
line  =  in. readLine 0 ; 

} / / end  outer  for 

in. close ( ) ; 

} 

catch  (lOException  e) 

{ 

System. out .print ( "Error :  "  +  e) ; 

System. exit (1) ; 

} 


try 

{ 

ps_pos  =  new  PrintWriter 
(new  BufferedOutputStream(new 
FileOutputStream( "botPos.dat”) ) ) ; 
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ps_pos,println("Key  Values  for  Position  Interpolator"); 
ps_pos . println ( "  " ) ; 
ps_pos , println ( "  " ) ; 

} 

catch  (lOException  e) 

{ 

System. out. print ("Error:  "  +  e) ; 

System. exit (1)  ; 


try 

{ 

ps_key  =  new  PrintWriter 
(new  BufferedOutputStream(new 
FileOutputStream( "botKey.dat") ) ) ; 

ps_key. println ("Key  for  Interpolators"); 
ps_key . println ( "  " ) ; 
ps_key , println ( "  " ) ; 

} 

catch  (lOException  e) 

{ 

System. out. print ("Error:  "  +  e) ; 

System. exit (1) ; 


try 

{ 


ps_angle  =  new  PrintWriter 
(new  Buf feredOutputStream(new 
FileOutputStream( "botAngle.dat") ) ) ; 

ps_angle.println("Key  Values  for  Orientation 

Interpolator"); 

ps_angle. println ("In  file  ") ; 
ps_angle . println ( "  " ) ; 

} 

catch  (lOException  e) 

{ 


System. out .print ( "Error :  "  +  e) ; 
System. exit (1) ; 


if  (TRACE) { 

for  (int  i=0;  i<16;  i++) 
for  (int  j=0;  j<2;  j++) 

System,  out.  println  ("speed_ar  ray  ["  +  j  +”][”  +  i  +  **] 
=  "  +  speed__array  [i]  [  j  ]  )  ; 

} 

}  / /  end  of  RobotClass  definition 
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public  void  get_command ( ) 

{ 


try 

{ 

Buf feredReader  in  =  new  Buf feredReader 
(new  FileReader ( "robot  tst . scr " ) ) ; 


PrintWriter  out  =  new  PrintWriter 

(new  BufferedWriter (new  FileWriter ( "botPos .dat" ) ) ) ; 


while  (EOF  !=  1){ 
readData (in) ; 
if  (EOF  !=  1) 


rightspd  =  "  + 
duration) ; 

) 


} 


System,  out. println ("leftspd  =  "  +  leftspeed  +  " 
rightspeed  +  "  duration  =  "  + 
compute^os  (leftspeed,  rightspeed)  ; 


writeKey  (ps_)cey) ; 
in. close  ( )  ; 


catch  (lOException  e) 

{ 

System. out. print ("Error:  "  +  e) ; 
System. exit (1) ; 

) 


public  void  run_program(int  ad_rdO,  int  ad  rdl) 

{ 

//System. out. println (ad_rdO  +  "  "  +  ad_rdl) ; 
if  (time  <=  SCENE_TIME) 

{ 

if  (ad_rdO  <=  48  &&  ad_rdl  <=  48) 

{ 

compute_pos (-8, 8) ;  //SLOW  SPIN  SEARCH 

} 

else  if  (ad_rdO  >  48  | |  ad_rdl  >  48) 

{ 

if  ( (ad_rdO  >=  400  &&  ad_rdl  >=400)  &&  (Math.abs(ad  rdO- 
ad_rdl)<=50)) 

compute_pos (8, 8) ;  //FINAL  DETECTION  MODE 

if  ( ( (ad_rd0<400  &&  ad_rd0>=250)  &&  (ad_rdl<400  && 
ad_rdl>=250) )  && 

(Math . abs ( ad_rdO-ad_rdl ) <=5  0 ) ) 

compute_pos (10, 10) ;//BOTH  EYES  EQUAL  NOT  QUITE  THERE  YET 
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if  (  (  (ad__rd0<250  &&  ad_rd0>=100)  &&  (ad_rdl<250  && 
ad_rdl>=100) )  && 

(Math. abs {ad_rdO-ad_rdl) <=50) ) 

compute_pos (12, 12) ;  //BOTH  EYES  EQUAL,  APPROACHING 

if  ((ad_rd0<100  &&  ad_rdl<100)  &&  (Math. abs (ad_rdO~ 
ad_rdl)<=50) ) 

compute__pos  (15, 15)  ;  //BOTH  EYES  EQUAL,  INITIAL 

ACQUISITION 


1000 


if  (ad_rdO-ad_rdl  >  2500) 

compute_pos (0, 12) ;  //SHARP  LEFT  TURN  DIFF  >  2500 

if  (ad_rd0“ad_rdl>1000  &&  ad_rd0-ad_rdl<=2500) 

compute_pos (0, 14) ; //SLOWER,  SHARP  LEFT  TURN,  DIFF  > 


if  (ad_rd0-ad_rdl>500  &&  ad_rd0“ad_rdl<=1000) 

compute_pos (-10, 10) ;  //SLOW  LEFT  TURN,  DIFF  >  500 

if  (ad_rd0“ad_rdl>50  &&  ad_rd0-ad_rdl<=500) 

coitipute_pos(-8,8)  ;  //LEFT  SEARCH  TURN,  DIFF  >  50 

i f  ( ad_rdl - ad_rd0>2  500) 

compute_pos (12, 0) ;  //SHARP  RIGHT  TURN  DIFF  >  2500 

if  (ad__rdl-ad_rd0>1000  &&  ad_rdl-ad_rd0<=2500 ) 

compute_pos (14, 0) ///SLOWER,  SHARP  RIGHT  TURN  DIFF  >1000 

if  (ad_rdl-ad_rd0>500  &&  ad__rdl-ad_rd0<=1000) 

compute^pos (10,-10) ;  //SLOW  RIGHT  TURN  DIFF  >  500 

if  (ad_rdl-ad_rd0>50  &&  ad_rdl-ad_rd0<=500) 
compute^pos (8,-8) ;  //RIGHT  SEARCH  TURN 


else  compute_pos (-8, 8) ; 

} 

else  writeKey (ps_key) ; 


//Member  Function:  compute_pos 
//Return  Value:  void 

//Parameter:  left_wheel_speed  and  right_wheel_speed 

//Purpose:  This  member  function  computes  the  new  position  of  the 

robot 

// 

private  void  compute_pos (int  leftspeed,  int  rightspeed) 

{ 

System,  out.  printing*  ")  ; 

System. out. println(**LWS  ==  "  +  leftspeed  +  "  "  +  "RWS  =  **  + 
rightspeed) ; 

if  (pc==0)  { 
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System. out. println(robotX  +  "  "  +  robotY  +  "  "  +  robotZ  + 

II  II  ^ 

robotTheta  +  "  "  +  time  +  "  "  +  key) ; 

writePos (ps_pos, robotX, robotY, robotZ) ; 
writeAngle (ps_angle, robotTheta) ; 

}//end  if 


pc++; 


/* 

180. Of)));*/ 


System. out.println( "Robot  Angle  =  "  + 

angle_norm( (rad_to_deg (robotTheta) - 


if  {  leftspeed  <  0  ) 

{ 


rpsorderl  =  -  speed_array[ (-leftspeed) ] [0] ; 

} 

else 

{ 

rpsorderl  =  speed_array [leftspeed] [0] ; 

} 


if  ( 
{ 

} 

else 

{ 

} 


rightspeed  <  0  ) 

rpsorder2  =  -  speed_array[ (-rightspeed) ][!]; 


rpsorder2  =  speed_array [rightspeed] [1] ; 


rpschangel  =  rpsorderl  -  rpsl; 
rpschange2  =  rpsorder2  -  rps2; 


if  (  {(rpsorderl  *  rpsl)  <=  O')  &&  rpsorderl  !=  0  ) 

{ 

if  (rpsorderl  >  0) 

deltal  =  accelDelta  /  timeStep; 
else 

deltal  =  -accelDelta  /  timeStep; 
transient Step si  =  rpschangel  /  deltal; 

} 

else  if  (  rpschangel  >  0  ) 

{ 

deltal  =  accelDelta  /  timeStep; 
transientStepsl  =  rpschangel  /  deltal; 

} 

else 

{ 

if  (rpsorderl  ==  0) 

deltal  =  -f reeDecelDelta  /  timeStep; 
else 

deltal  =  -  drivenDecelDelta  /  timeStep; 
transientStepsl  =  rpschangel  /  deltal; 

) 
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if  (  (  (rpsorder2  *  rps2)  <=  0  )  &&  rpsorder2  !=  0  ) 

{ 

if  (  rpsorder2  >  0  ) 

delta2  =  accelDelta  /  timeStep; 
else 

delta2  =  -  accelDelta  /  timeStep; 
transientSteps2  =  rpschange2  /  delta2; 

} 

else  if  (  rpschange2  >  0  ) 

{ 

delta2  =  accelDelta  /  timeStep; 
transientSteps2  =  rpschange2  /  delta2; 

} 

else 

{ 

if  (  rpsorder2  ==  0  ) 

delta2  =  -  freeDecelDelta  /  timeStep; 

else 

delta2  =  -  drivenDecelDelta  /  timeStep; 
transientSteps2  =  rpschange2  /  delta2; 

} 

numsteps  =  duration  *  timeStep; 

for  (int  step  =0;  step  <  numsteps;  step++) 

{ 

rpsl  +=  deltal; 
rps2  +=  delta2; 

float  rad_of_curv  =  O.Of; 
float  bot_ang_vel  =  O.Of; 
float  deltaTheta  =  O.Of; 
float  deltaThetaHalf  =  O.Of; 
float  cons  =  O.Of; 
float  travell  =  O.Of; 
float  travel2  =  O.Of; 

float  LEFT_WHEEL_SPD  =  rpsl; 
float  RIGHT_WHEEL_SPD  =  rps2; 

//System,  out  .println  (bot_ang__vel )  ; 

//  Are  the  wheels  traveling  exactly  the  same  (ie  speed  x  dia 

the  same 

//  for  each)  ?  THIS  IS  NOT  THE  DISTANCE  TRAVELED!!!! 
travell  =  LEFT_WHEEL_SPD  *  left_wheel_diam  /  2; 
travel2  =  RIGHT_WHEEL_SPD  *  right_wheel_diam  /  2; 

if  {  travell  ==  travel2  )  //  traveling  in  a  straight  line 

robotX  +=  travell  *  (float ) Math. sin (  robotTheta  )  / 
(float)  timeStep; 

robotZ  +=  travell  *  ( float) Math. cos (  robotTheta  )  / 
(float)  timeStep; 
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deltaTheta  =  O.Of; 


) 

else 

{ 

rad_of_curv  ==  (  (  LEFT_WHEEL_SPD  *  left_wheel_diam  + 
RIGHT_WHEEL_SPD  *  right_wheel_diam  )  / 

(  LEFT_WHEEL_SPD  *  lef t_wheel_diam  - 
RIGHT_WHEEL_SPD  *  right_^wheel_diam  )  )  * 

(  wheel___base  /  2.  Of  ); 

//if  (TRACE) 

//System. out .println ( "radius  of  curv  =  ”  +  rad  of  curv  ); 

bot_ang_vel  ==  (  LEFT_WHEEL_SPD  *  lef t__wheel_diam  - 
RIGHT_WHEEL_SPD  *  right_wheel__diam  )  * 

(float) Math. PI  /  wheel___base; 

if  (TRACE) 

System. out. println("bot__ang_vel  =  "  +  bot_ang_vel)  ; 

deltaTheta  =  bot_ang_vel  /  (float)  timeStep;  //  timeStep 
is  #  of  steps  per  second 
if  (TRACE) 

System.  out.println( "deltaTheta  =  "  +  deltaTheta); 

deltaThetaHalf  =  deltaTheta  /  2, Of; 

cons  =  2.0f  *  rad_of_curv  *  (float) Math. sin ( 
deltaThetaHalf  ) ; 

if  (TRACE) 

System.out .println ("cons  =  ”  +  cons); 

robotX  +=  cons  *  (float) Math. sin (  robotTheta  + 
deltaThetaHalf  ) ; 

robot Z  +=  cons  *  ( float) Math. cos (. robotTheta  + 
deltaThetaHalf  ) ; 

}  //  end  else  (  travell  !=  travel2  ) 

robotTheta  +=  deltaTheta; 

if  (  step  >=  transientStepsl  ) 

{ 

deltal  =0; 
rpsl  =  rpsorderl; 

} 

if  (  step  >=  transientSteps2  ) 

{ 

delta2  =  0; 
rps2  =  rpsorder2; 

} 

time  +=  (  1  /  (float)  timeStep  ) ;  ; 

}  //  end  for  (  int  index  =  0;  index  <  numsteps;  index++  ) 

float  angle  =  beac_rel__angle(robotX,robotZ,beacX,beacZ); 
System. out .println ( "angle  =  ”  +  angle); 
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float  tend_angle  —  180. Of  +  angle_nonn( (rad_to  deg (robotTheta) 

-  angle) ) ;  “  ~ 

float  beac_dist  = 

beac_range ( robotX, robotZ , beacX,  beacZ , robotTheta ) ; 

float  bcn_int_fact  =  bcn_xmit_int  (INIT_BCN_VOLT,  time)  ; 
beac_freq  =  bcn_flsh_freq(INIT_BCN_VOLT,  time,  beac_freq) ; 

float  det_volt_fact  =  det_sply_volt (INIT_EC_VOLT, time) ; 
float  f req_rsp_fact  =  filter {asgn_beac_freq,beac  freq, sigma); 

Left_AD  = 

bot_detector (beac_dist,beac_freq,  tend_angle,bcn_int_fact, 

det_volt_fact,  freq_rsp_fact,  0) ; 

Right_AD  = 

^ot_detector (beac_dist,beac_freq, tend_angle,bcn  int  fact, 

det_volt_fact, freq_rsp_fact,  1); 

System. out. println( "Left  Eye  =  "  +  Left  AD  +  "  Right  Eye  = 

"  +  Right_AD) ; 

System. out. println(robotX  +  "  "  +  robotZ  +  "  "  +  robotTheta  + 

"  "  +  time); 


System. out. println( "Range  from  beacon  =  "  +  beac  dist) ; 

System. out. println( "Eye  Angle  =  "  +  ~ 

angle_norm(rad_to_deg( robotTheta) )  )  ; 

System. out. println( "Relative  angle  of  beacon  to  robot  =  "  + 
angle_norm(90. Of-angle) )  ; 

System. out. println( "Angle  between  eyes  and  beacon  =  "  + 
tend_angle) ; 

System. out. printlnC'PC  =  "  +  pc); 

if  (  {  pc  %  5  )==0  &&  pc  !=0  )  { 

System. out. println (robotX  +  "  "  +  robotY  +  "  "  +  robotZ  + 

•I  fl 

robotTheta  +  "  "  +  time  +  "  "  +  key) ; 

writePos (ps_pos , robotX,  robotY, robotZ ) ; 
writeAngle (ps_angle, robotTheta) ; 

}//end  if 

run_j)rogram  (Left_AD, Right_AD) ; 

}  //  end  compute_pos 


//Member  Function;  bcn_xmit_int 

//Return  Value;  float  ==>  fraction  of  total  intensity  transmitted 
by  beacon 
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//Parameter:  freq  ==>  frequency  at  which  beacon  oscillator  is  set 

/ /  volt  =“>  measured  voltage  of  battery  used  to  power 

beacon  oscillator 

//  time  ==>  amount  of  time  gone  by  in  scenario 

//Purpose:  This  member  function  computes  the  fraction  of  total 

intensity  transmitted 

//  by  the  beacon 

// 

private  float  bcn__xinit_int  (float  volt,  float  time) 

{ 

float  volt_init  =  volt; 
float  volt_drop  =  time  *  5.56e-5f; 
float  volt_final  =  volt_init  -  volt_drop; 
float  int  fract  =  l.Of; 


if  (volt_final  <  4.5f  &&  volt_final  >=  3. Of) 

{ 

float  volt_drop2  =  4.5f  -  volt_final; 
float  int_delta  =  volt_drop2  *  .1267f; 
int_fract  =  int_fract  -  int_delta; 

} 

if  {volt_final  <  3. Of  &&  volt_final  >=  1.5f) 

{ 

float  volt_drop3  =  3. Of  -  volt_final; 
float  int__delta  =  volt_drop3  *  .533f; 
int_fract  =  .8f  -  int__delta; 

} 


if  (volt_final  <  1.5f) 

{ 

int_fract  =  O.Of; 

} 


Int. 


} 


if  (TRACE)  System. out. println ("Voltage  Drop 
Fract  =  "  + 

int_fract) ; 

return  int  fract; 


+  volt__drop  +  ” 


//Member  Function:  bcn_flsh__f req 

//Return  Value:  float  ==>  voltage  dependent  flash  frequency  of 
beacon 

//Parameter:  freq  ==>  frequency  at  which  beacon  oscillator  is 

initally  set 

/ /  volt  ==>  measured  voltage  of  battery  used  to  power 

beacon  oscillator 

/ /  time  ==>  amount  of  time  gone  by  in  scenario 

//Purpose:  This  member  function  computes  the  voltage  dependent 

flash  frequency  of 

/ /  the  beacon 

// 

private  float  bcn_flsh_freq  ( float  volt,  float  time,,  float  freq) 
float  volt  init  =  volt; 
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float  volt_drop  =  time  *  5.56e-5f; 
float  volt_final  =  volt_init  -  volt__drop; 

float  freq_drop  =  volt_drop  /  .0432f; 
float  freq_final  =  freq  -  freq_drop; 


Volt 

"  + 


if  (TRACE)  { 

System. out. println("Init. Volt.  =  "  +  volt  init  +  "  Final 

"  + 

volt_final) ; 

System, out. println ("Init.  freq  =  ”  +  freq  +  "  Final  freq.  = 


} 


freq__final)  ; 


return  freq_final; 

) 


//Member  Function:  det_sply_volt 

//Return  Value:  float  ==>  fraction  of  total  detector  intensity 
received  as 

II  as  result  of  its  dependence  on  detector 

supply  voltage 

//Parameter:  volt  ==>  measured  voltage  of  battery  used  to  power 

electrical  circuit 

/ /  time  ==>  amount  of  time  gone  by  in  scenario 

//Purpose:  This  member  function  computes  the  voltage  dependent 

intensity  received  by 

/ /  the  detector 

// 

private  float  det_sply_volt ( float  volt,  float  time) 

{ 

float  volt^init  =  volt; 

float  volt__drop  =  time  *  5.56e-5f; 

float  delta__int  =  volt_drop  *  .0391f; 

float  int_fact  =  l.Of  -  delta_int; 

return  int_fact; 

} 


//Member  Function;  filter 

//Return  Value:  float  ==>  fraction  of  total  detector  intensity 
received  as 

! !  as  result  of  its  dependence  on  the 

frequency 

/ !  response  of  the  electrical  circuit 

(bandpass  filter) 

//Parameter:  asgn_beac_f req  ==>  assigned  beacon  frequency 

/ /  beac_freq  ==>  reduced  beacon  freq  as  a  result  of 

time  and  voltage 

/ /  dependence 

/ /  sigma  ==>  corrected  characteristic  width  of 

freq  response  curve 


95 


//Purpose;  This  member  function  computes  the  fraction  of  total 
detector  intensity 

/ /  received  as  as  result  of  its  dependence  on  the  frequency 

// 

private  float  filter (float  ass^freq,  float  curr_freq,  float  sigma) 

{ 

float  del^freq  =  Math. abs (ass_f req  -  curr^freq) ; 
float  frac  =  (float)Math.exp ( (double) - (del_freq*del_freq) / (2 . Of  * 
sigma  *  sigma)  )  ; 

return  frac; 

} 


//Member  Function;  bot_detector 

//Return  Value;  int  ==>  received  intensity  by  detector  in  terras  of 
A/D  integer 

//Parameter;  range, freq  =->  Distance  and  angle  of  beacon  from 
robot; 

/ /  and  frequency  of  beacon 

/ /  MAX__AD_INT  ==>  max  intensity  detector  capable  of 

producing  due  to 

//  intensity  received  by  beacon,  detector 

supply  voltage, 

//  and  frequency  filter  function 

//Purpose:  This  member  function  computes  the  received  intensity  by 

detector  in  terms  of  A/D  integer 

// 

public  int  bot_detector (float  range, float  freq, float 
tend__angle,  float  bcn_int_fact, 

float  det_volt__fact,  float 

freq_rsp_fact, int  lr_eye) 

{ 

int  rcvd_int  =  MIN_NOISE_INT  ; 
int  LEFT_EYE_INT  =  rcvd__int; 
int  RIGHT_EYE_INT  =  rcvd_int; 
boolean  reye__detect  =  false; 
boolean  leye^detect  =  false; 

boolean  value  =  false;  //if  computations  are  finished,  value  is 
true  and  loop  stops 

if  (TRACE)  System. out. println(”Bcn  int  fract  =  *•  +  bcn_int_fact  +  "  EC 
volt  Fact  =  ”  + 

det_volt_fact  +  "  Freq  resp  fact  =  "  + 

freq___rsp_fact)  ; 

if  (tend_angle  <=  90, Of  &&  tend^angle  >=0.0f)  leye_detect  =  true; 
if  (tend_angle  <=  360. Of  &&  tend_angle  >=  270. Of)  reye_detect  = 

true; 


while  {  (leye_detect  |  |  reye^detect)  &&  lvalue  ) 

{ 

if  (range  >  MAX_DET_DIST) 

{ 

leye^detect  =  reye^detect  =  false; 
break; 


96 


} 

if  (range  <=  MAX_SAT_DIST) 

{ 

rcvd_int  =  (int) (bcn_int_fact  *  det_volt_fact  * 
freq_rsp_fact  *  MAX_AD_INT  ) ; 

) 


else  rcvd_int  =  (int) (bcn_int_fact  *  det_volt_fact  * 
freq_rsp_fact  *  MAX_AD_INT  * 


(range*range) ) ) ; 


(  (MAX_SAT_DIST  *  MAX_SAT  DIST)  / 


rcvd_int  =  eye_ang_dep (rcvd_int,  tend_angle) ; 

LEFT_EYE_INT  =  discriminate ( rcvd_int,  tend_angle, leye_detect) ; 
RIGHT_EYE_INT=  discriminate (rcvd_int,  tend_angle, reye~detect) ; 

if  (LEFT_EYE_INT  <  MIN_NOISE_INT)  LEFT_EYE  INT  = 
MAX_NOISE_INT;  ~ 

if  (RIGHT_EYE_INT  <  MIN_NOISE_INT) RIGHT  EYE  INT= 

MAX_NOI SE_INT ;  ~ 

value  =  true; 

} 

if  (lr_eye  ==  0)  rcvd_int  =  LEFT_EYE_INT ; 
if  (lr_eye  ==  1)  rcvd_int  =  RIGHT_EYE_INT; 

return  rcvd_int; 

} 


//Member  Function:  eye  ang  dep 

//Return  Value:  int  ==>  received  intensity  by  detector  in  terms  of 
A/D  integer 

//Parameter:  rcvd_int  ==>  on-axis  intensity  received  by  eyes, 

dependent  on  range  only 

//Purpose:  This  member  function  applies  an  angular  dependency  to 

the  on-axis  intensity 

// 

private  int  eye_ang_dep ( int  intensity,  float  angle) 

{ 

angle  =  deg_to_rad ( angle ) ; 

intensity  =  (int) ( (float) intensity  *  ( float) Math. cos (angle) ) ; 
return  intensity; 

} 

//end  eye_ang_dep 


//Member  Function:  discriminate 

//Return  Value:  int  ==>  received  intensity  by  detector  in  terms  of 
A/D  integer 

//Parameter:  rcvd_int  ==>  integer  value  of  angle  dependent 

intensity  received  by  eyes 

/ /  angle  ==>  float  value  angle  which  beacon  light 

tends  to  eyes 
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==>  boolean  value  that  tells  which  side 


/  /  side 

beacon  is  detected  on 

//Purpose:  This  member  function  applies  an  eye  nose  and  shadowing 

dependency  to  the  detector 

/ /  received  intensity  in  order  to  give  it  left  and  right 

eye  discrimination 

private  int  discriminate (int  rcvd_int,  float  angle,  boolean  side) 

{ 

int  intensity  =  rcvd_int; 

float  theta_max  =  (float)Math. atan2 ( (T0T_EYE_SEP/2 . Of  + 
EYE_LENGTH) ,NOSE_LENGTH) ; 
float  theta_min  = 

(float)Math.atan2 ( (T0T_EYE_SEP/2 . Of) ,NOSE_LENGTH) ; 
angle  =  deg_to_rad (angle) ; 

float  DISCR_LENGTH  =  Math. abs (NOSE_LENGTH  * 

(float) Math. tan (angle) ) ; 

if  (rad_to_deg (angle)  >=  270. Of) 

{ 

float  T_MAX  =  theta_max; 

theta_max  =  (2. Of  *  (float) Math. PI)  -  theta_min; 
theta_min  =  (2. Of  *  (float) Math. PI)  -  T_MAX; 

. } / / end  i f 

if  (Iside) 

{ 

if  (rad_to_deg (angle)  >=  270. Of) 

{ 

if  (angle  <=  theta_min)  intensity  =  MAX_NOISE_INT; 
if  (angle  >=  theta_max)  intensity  =  rcvd_int; 
if  (angle  >  theta_min  &&  angle  <  theta_max) 
intensity  =  (int) (rcvd_int  * 

((l.Of  +  (TOT_EYE_SEP  /  2 . Of ) /EYE_LENGTH)  - 
DISCR_LENGTH/EYE_LENGTH) ) ; 

) 

else 

{ 

if  (angle  <=  theta_min)  intensity  =  rcvd_int; 
if  (angle  >=  theta_max)  intensity  =  MAX_NOISE_INT; 
if  (angle  >  theta_min  &&  angle  <  theta_max) 
intensity  =  (int) (rcvd_int  *  ~ 

((l.Of  +  (TOT_EYE_SEP  /  2 . Of ) /EYE_LENGTH)  - 
DISCR_LENGTH/EYE_LENGTH) ) ; 

) 

}//end  if  ( Iside) 

//System. out .println ("theta_max  =  "  +  rad_to_deg (theta  max)  + 
"theta_min  ="  + 

/ /  rad_to_deg (theta_min) )  ; 

return  intensity; 

} 


//Member  Function:  beac_range 
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//Return  Value:  floating  point  value  of  range  from  beacon  to  robot 
or  robot  eyes 

//Parameter:  botx,botz,beacx,beacz,bot_angle  ==>  Robot  * s  and 
Beacon  *  s  Position 

//Purpose:  This  member  function  computes  range  of  the  beacon  to  the 

robot  from  robot  center 

//  and  additionally  computes  the  range  of  the  beacon  to  the 

robot  *  s  eyes 

// 

public  float  beac_range  (float  botx,  float  botZ;.  float  beacx,  float 
beacz, float  bot^angle) 

{ 

float  range_beac; 

float  eye_x  =  botx  +  bot_radius  *  ( float) Math. sin (bot__angle)  ; 

float  eye_z  =  botz  +  bot_radius  *  ( float) Math. cos (bot_angle) ; 

float  range_eyes  =  ( (eye_x-beacx) * (eye_x-beacx) )  +  ( (eye^z- 
beacz)  *  (eye_z-beacz) ) ; 

range_eyes  =  ( float ) Math. sqrt (range_eyes ) ; 

//System. out.println( "Eye  range  from  beacon  =  "  +  range_eyes) ; 

range^beac  =  (  (botx-beacx) * (botx-beacx) )  +  (  (botz-beacz)  * 
(botz-beacz) ) ; 

range_beac  =  ( float ) Math. sqrt (range_beac) ; 

return  range_eyes; 

} 

//end  beac_range 


//Member  Function:  beac_rel__angle; 

//Return  Value:  float 

//Parameter:  botx, botz, beacx, beacz  ==>  Robot's  and  Beacon's 

Position 

//Purpose:  This  member  function  computes  the  relative  angle  of  the 

beacon 

//  to  the  robot 

// 

public  float  beac__rel_angle  (float  botx,  float  botz,  float  beacx, 
float  beacz) 

{ 

float  beac__theta; 
float  X  =  botx  “  beacx; 
float  z  =  botz  -  beacz; 

beac_theta  =  ( float) Math . atan2 (x, z ) ; 
beac_theta  =  {rad_to_deg (beac_theta) ) ; 
if  (beac_theta  <  0)  { 
beac_theta  +=  360.0; 

} 

return  angle_norm(beac_theta) ; 

} 

//end  beac 


//Member  Function:  angle_norm; 
//Return  Value:  float 
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//Parameter:  theta  ==>  an  angle  in  degrees 

//Purpose:  This  member  function  normalizes  and  anlge  so  that  its 

value  always 

/ /  falls  between  +0  and  +360 

private  float  angle_norm( float  theta) 

{ 

while  (theta  <  O.Of  ||  theta  >  360. Of) 

{ 

if  (theta  <  O.Of)  theta  +=  360. Of; 

if  (theta  >  360. Of)  theta  -=  360. Of; 

} 

return  theta; 

} 

//end  angle_norm; 


//Member  Function:  rad_to_deg; 

//Return  Value:  float 

//Parameter:  radians  ==>  an  angle  in  radians 

//Purpose:  This  member  function  converts  an  angle  given  in  radians 

to  degrees 

// 

public  float  rad_to_deg ( float  radians) 

{ 

float  degrees; 

degrees  =  (float) ( (radians  /  ( float) Math. PI )  *  180.0); 
return  degrees; 

} 

//end  rad_to_deg 


//Member  Function:  deg_to_rad 
//Return  Value:  float  ~  ~ 

//Parameter:  degrees  ==>  an  angle  in  degrees 

//Purpose:  This  member  function  converts  an  angle  given  in  degrees 

to  radians 

// 

public  float  deg_to_rad ( float  degrees) 

{ 

float  radians; 

radians  =  (degrees  *  ( (float)Math. PI  /  180. Of)); 
return  radians; 

) 

/ / end  deg_to_rad 


private  void  writePos (PrintWriter  out,  float  x,  float  v,  float  z) 

{ 

z  =  18. Of  -  z;  //this  compensates  for  coordinate  system  of  VRML 
playing  field 

out . flush ( ) ; 
i++; 

out. print (x  +  "  "  +  "  "  +  y  +  "  "  +  z  +  ","); 
out . flush ( ) ; 
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} 


if  (i%3  ==  0) 

out . println ( "  ” ) ; 
out. flush ( ) ; 


private  void  writeAngle(PrintWriter  out,  float  theta) 

{ 


theta  =  (2. Of  *  (float) Math. PI)  -  theta;  //this  compensates  for 
coord,  sys.  of 

/ /  VRML  playing  field 

out . flush ( ) ; 


k++; 

out. print ("0.0  1.0  0.0  ”  +  theta  +  ”,  ”); 

out. flush ( ) ; 

if  (k%3  ==  0) 

out . println { ”  ” ) ; 

out . flush ( ) ; 


private  void  writeKey (PrintWriter  out) 

{ 

out. flush ( ) ; 

float  key_interval  =  l.Of  /  {( float) SCENE_TIME  /  0.5f); 
float  key  =  0. Of; 
key  -=  key_interval; 

for  (  int  i=0;  i  <=  (int) (SCENE_TIME  /  0.5f);  i++) 

{ 

key  +=  key_interval; 
if  (i  ==  0)  key  =  0; 

out .print (key  +  ”  ”) ; 
if  (i  !=0  &&  i%5  ==  0) 

{ 

out .println (”  ”) ; 

} 

} 

out. flush ( ) ; 


public  static  void  readData (Buf feredReader  in)  throws  lOException 

{ 

Integer  intobj  =  new  Integer (0); 

String  line  =  in. readLine ( ) ; 
if  (line  ==  null) 

{ 


EOF  =  1; 
return; 
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} 

StringTokenizer  t  =  new  StringTokenizer (line,  " 

leftspeed  =  intobj.parseInt(t.nextToken{)); 
System,  out.  printlnC'leftspeed  ="  +  leftspeed); 
rightspeed  =  intobj.parseInt(t.nextToken()); 
System. out . println { "rightspeed  ="  +  rightspeed) 
duration  =  intobj .parseint (t.nextToken ( ) ) ; 
System. out. println ("duration  ="  +  duration); 


public  static  void  main (String [ ]  args) 

{ 

//PrintWriter  VRML  file; 


Simbot  BWl  =  new  Simbot ( ) ; 
/ /BWl . get_command ( ) ; 
BWl.run_program(16, 16) ; 


) 


\n\t\r") 
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//  FUe:  robotcon  (ASCII) 

//  Author:  LT  Wm.  Ben  McNeal 
//  Subject:  Simbot  Configuration  Program 
//  Operating  Environment:  NA 
//Browser:  NA 

//  Description:  This  program  contains  all  of  the  physical  characteristics  for  the 
Simbots  (le.,  wheels  speed,  acceleration,  deceleration) 

//Inputs:  None 
//Outputs:  None 

// Last  compile/run  date:  18  December  1997 
//Warnings:  None 


//  Robot  config  -  do  not  change  comments  around!  Bad  things  happen, 

/ /  Acceleration  constant  rev  per  second  per  second 
3.4 

/ /  Deceleration  with  one  wheel  driven  rev  per  sec  per  sec  - 

drivenDecelDelta 

0.35 

/ /  Deceleration  with  no  wheels  driven  rev  per  sec  per  sec 
0.84 

//  Wheel  diameters  in  feet  PORT  (wheel  1)  STBD  (wheel  2) 

.2742  .2755 

/ /  Wheel  base  feet 

.750 

/ /  Angular  velocities  in  revolutions  per  second,  PORT  STBD,  speed  1  1 
1.2  1.2 
/ /  Speed  2  2 
0.2984  0.3182 
II  Speed  3  3 
0.4096  0.4247 
/ /  Speed  4  4 
0.5388  0.5557 
/ /  Speed  5  5 
0.6526  0,6609 
/ /  Speed  6  6 
0.7555  0.7711 
//  Speed  7  7 
0.8656  0.8677 
//  Speed  8  8  0.9802 
0.9573  0.9802 
/ /  Speed  9  9 
1.0716  1.0779 
/ /  Speed  a  a 
1.1714  1,2021 
/ /  Speed  b  b 
1.2854  1.2893 
/ /  Speed  c  c 
1.4331  1.4100 
//  Speed  d  d 
1.5154  1.4302 
/ /  Speed  e  e 
1.6279  1.6560 
/ /  Speed  f  f 
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1.7234  1.6555 
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APPENDIX  B:  INTERPOLATOR  DATA  OUTPUT  FILES 


The  JAVA  class,  Simbotclass  outputs  the  positional  and  rotational  data  for  each 
Simbot  into  sets  of  output  data  files,  which  the  graphics  program  uses  to  replicate  the 
Simbots’  behavior  and  movements.  The  output  files  consist  of  three  text  files  for  each 
Simbot.  The  first  gives  the  keys  for  each  of  the  Simbot  positions  listed  in  the  previous 
two  output  files.  The  second  gives  the  x,  y,  and  z  positions  (key  values)  of  the  Simbot. 
The  third  gives  the  rotational  position  (key  value)  in  terms  of  axis  of  rotation  and  the 
amount  of  rotation  around  that  axis  for  each  key.  In  VRML,  the  entire  detection  sequence 
scenario  is  scaled  in  time  from  0.0  to  1.0.  For  example,  if  the  entire  scenario  lasts  360 
seconds  (3  minutes),  and  we  wish  to  use  intervals  of  0.5  seconds  to  animate  the  Simbot’s 
movement,  there  would  be  721  (360  *  0.5  +  1)  equally  spaced  keys  between  0  and  1 
corresponding  to  the  721  0.5  second  time  intervals.  This  appendix  lists  examples  of  each 
of  the  output  files  for  a  10  second  scenario.  They  are  listed  in  the  JAVA  source  code  as 
botlPos.dat,  bot2Pos.dat,  botlAngle.dat,  bot2Angle.dat,  botlKey.dat,  and 
bot2Key.dat. 


Key  for  Interpolators 

0.0  0.05  0.1  0.15  0.2  0.25  0.3  0.35000002  0.40000004 
,0.45000005  0.5  0.5500001  0.6000001  0.6500001  0.7000001  0.7500001 
0.80000013  0.85000014  0.90000015  0.95000017  1.000000 


Key  Values  for  Orientation  (Rotation)  Interpolator 

0.0  1.0  0.0  3.1415927,0.0  1.0  0.0  3.3534286, 

0.0  1.0  0.0  4.23458,  0.0  1.0  0.0  3.9552665, 

0.0  1.0  0.0  3.772439,  0.0  1.0  0.0  3.8656433, 
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0.0  1.0  0.0  3.8196476,0.0  1.0  0.0  3.8038297, 

0.0  1.0  0.0  3.8271668,0.0  1.0  0.0  3.850504, 

0.0  1.0  0.0  3.873841,  0.0  1.0  0.0  3.8580232, 

0.0  1.0  0.0  3.8813603,0.0  1.0  0.0  3.9046974, 

0.0  1.0  0.0  3.9280345,  0.0  1.0  0.0  3.9513717, 

0.0  1.0  0.0  3.9747088, 


In  this  output  file  the  key  “0.0  1.0  0.0  3.3534286”  is  interpreted  as  no  rotation 
about  the  x-axis  or  z-axis.  The  only  rotation  is  about  the  y-axis,  indicated  by  the  1 .0  key 
value.  The  last  value  indicates  the  amount  of  rotation  about  the  y-axis  and  is  given  in 
radians. 


Key  Values  for  Position  Interpolator 

15.5  0.425  2.5,  15.496904  0.425  2.527234,15.313581  0.425  2.7498045, 

15.076797  0.425  2.8778868,14.956533  0.425  3.0596962,14.7258625  0.425 

3.2966442, 

14.454755  0.425  3.6119413,14.187247  0.425  3.93326,13.924856  0.425 

4.258769, 

13.667647  0.425  4.5883875,13.419444  0.425  4.9063673,13.159762  0.425 

5.234042, 

12.904133  0.425  5.546115,12.646233  0.425  5.856286,12.383597  0.425 

6.1624784, 

12.106548  0.425  6.475608,11.834393  0.425  6.7733717,11.557702  0.425 

7.0669107, 

11.274251  0.425  7.353915,10.986435  0.425  7.6365385,10.6898985  0.425 

7.9100037 


In  this  output  file  the  key  “1 5 . 5  0.425  2.5”  is  interpreted  as  a  positions  of  1 5 . 5 
relative  to  the  x-axis,  0.425  relative  to  the  y-axis  and  2.5  relative  to  the  z-axis. 
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APPENDIX  C:  VRML  SOURCE  CODE 


The  following  source  code  listed  in  this  appendix,  Simbotwrl,  is  used  to  generate 
the  3-dimensional  animated  scene  of  the  Simbot  detection  and  tracking  sequences.  The 
contents  of  the  interpolator  output  files  listed  in  the  previous  appendix  are  “copied  and 
pasted”  into  this  code. 
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//  File:  Simbotwrl  (VRML  file) 

//  Author:  LT  Wm.  Ben  McNeal 

//  Robot  Wars  Simulation  Graphics  Program 

//  Operating  Environment:  Windows  NT,  Windows  ‘95/’97,  IRIX  6.* 

//  Browser:  CosmoPlayer  1.0 

//  Description:  This  program  animlates  the  movement  of  two  Simbots  engaged  in 
a  series  of  detection  and  tracking  sequences 
//Inputs:  See  Appendix  B 
//  Outputs:  None 

//  Last  compile/run  date:  18  December  1997 
//Warnings:  None 

#VRML  V2.0  utf8 


DEF  RobotWorld  Group { 
children  [ 

Background  { 

skyColor  [0.8  0.8  0.8, 

0.8  0.8  0.8, 

0.8  0.8  0.8 

] 

skyAngle  [1.309,  1.571] 

) 

Navigationinfo  { 

type  "EXAMINE" 

} 

Viewpoint { 

description  "Front  Center  View" 
position  9.0  8.0  28.5 
fieldOfView  .916 

} 

Viewpoint] 

description  "Back  View" 
position  9.0  8.0  -11.0 
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orientation  0.0  1.0  0.0  3.14 


fieldOfView  .916 

} 

Viewpoint { 

description  "Right  Side  View" 
position  28.0  8.0  10.0 
orientation  0.0  1.0  0.0  1.57 
fieldOfView  .916 

} 

Viewpoint { 

description  "Right  Side  Robot  Level" 
position  18.0  4.0  10.0 
orientation  0.0  1.0  0.0  1.57 
fieldOfView  .916 

} 

Viewpoint { 

description  "Left  Side  View" 
position  -10.0  8.0  10.0 
orientation  0.0  1.0  0.0  -1.57 
fieldOfView  .916 

} 

Viewpoint! 

description  "Left  Side  Robot  Level" 
position  -0.0  4.0  10.0 
orientation  0.0  1.0  0.0  -1.57 
fieldOfView  .916 

} 

Viewpoint! 
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description  "Back  Center  Robot  Level” 
position  9.0  4.0  0.0 
orientation  0.0  1.0  0.0  3.14 
fieldOfView  .916 

) 

Viewpoint { 

description  "Front  Center  Robot  Level” 
position  9.0  4.0  14.0 
fieldOfView  .916 

} 

Viewpoint { 

description  "Front  Right  Corner  Level” 
position  1.0  4.0  0.0 
orientation  0.0  1.0  0.0  3.84 
fieldOfView  1.047 

} 

Viewpoint { 

description  "Front  Left  Corner  Level” 
position  17.0  4.00.0 
orientation  0.0  1.0  0.0  2.443 
fieldOfView  1.047 

) 

Viewpoint! 

description  "Beacon  Display” 
position  “30.0  9.0  9.25 
fieldOfView  .225 
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Viewpoint { 

description  "Robot  Display" 
position  57.5  9.0  4.25 
fieldOfView  .225 


Viewpoint { 

description  "Gun  Display" 
position  14.0  9.0  4.25 
fieldOfView  .225 


Transform! 

rotation  0.0  1.0  0.0  6.28 
children [ 

Inline!  url  "botfloor.wri"} 


] 

} 


#ROBOT2 

Transform  ! 

translation  0.0  2.0  -1.0 
children  [ 

Viewpoint! 

description  "Robot  2  Eye  Level" 
position  0.0  1.0  -1.0 
fieldOfView  .916 


} 

DEF  BOT2MOV  Transform! 

scale  0.0833  0.0833  0.0833 
translation  9.0  0.425  9.0 


rotation  0.0  1.0  0.0  3.14 
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children [ 


DEF  Robotl  Inline {  url  "robot2.wri”} 


#R0B0T1 

Transform  { 

translation  0.0  2.0  -1.0 
children  [ 

Viewpoint { 

description  "Robot  1  Eye  Level" 
position  0.0  1.0  -1.0 
fieldOfView  .916 

} 

DEF  BOTMOV  Transform{ 

scale  0.0833  0.0833  0.0833 
translation  0.0  0.425  18.0 
#rotation  0.0  1.0  0.0  3.14 
children [ 

DEF  Robotl  Inline {  url  "robot.wri"} 

] 

) 

#Touch  Sensor 

DEF  TouchBot  TouchSensor { } 

#  Animation  Clock 

DEF  Clock  TimeSensor  { 
cycleinterval  20.0 
stopTime  0 . 0 
startTime  1 . 0 
loop  TRUE 

), 

#  Animation  path 

DEF  BotPath  Positioninterpolator { 
key  [  0.0  0.05  0.1  0.15  0.2  0.25 

0.3  0.35000002  0.40000004  0.45000005  0.50000006 
0.5500001  0.6000001  0.6500001  0.7000001  0.7500001 
0.80000013  0.85000014  0.90000015  0.95000017  1.0000 

] 

keyValue  [15.5  0.425  2.5,15.496904  0.425  2.527234,15.313581 

0.425  2.7498045, 

15.076797  0.425  2.8778868,14.956533  0.425  3.0596962,14.7258625  0.425 

3.2966442, 

14.454755  0.425  3.6119413,14.187247  0.425  3.93326,13.924856  0.425 

4.258769, 

13.667647  0.425  4.5883875,13.419444  0.425  4.9063673,13.159762  0.425 

5.234042, 

12.904133  0.425  5.546115,12.646233  0.425  5.856286,12.383597  0.425 

6. 1624784, 

12.106548  0.425  6.475608,11.834393  0.425  6.7733717,11.557702  0.425 

7.0669107, 
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11.274251  0.425  7.353915,10.986435  0.425  7.6365385,10.6898985  0.425 

7.9100037, 

] 

} 

#Rotation  Path 

DEF  BotAngle  Orientationinterpolator  { 
key  [0.0  0.05  0.1  0.15  0.2  0.25 

0.3  0.35000002  0.40000004  0.45000005  0.50000006 
0.5500001  0.6000001  0.6500001  0.7000001  0.7500001 
0.80000013  0.85000014  0.90000015  0.95000017  1.0000] 


1.0 

o 

o 

keyValue  [0.0 
2.0486054, 

1.0 

o 

o 

3.1415927, 

0.0  1.0  0.0 

2.9297569, 

o 

o 

1.0 

0.0 

0.0 

2.4175422, 

1.0 

0.0 

2.327919, 

0.0  1.0  0.0 

2.5107465, 

0.0 

1.0 

0.0 

0.0 

2.4710572, 

1.0 

0.0 

2.4394214, 

0.0  1.0  0.0 

2.4552393, 

0.0 

o 

1— 1 

0.0 

0.0 

2.4793558, 

1.0 

0.0 

2.486875, 

0.0  1.0  0.0 

2.463538, 

0.0 

1.0 

0.0 

0.0 

2.4093444, 

1.0 

0.0 

2,4560187, 

0.0  1.0  0.0 

2.4326816, 

0.0 

1.0 

0.0 

0.0 

2.378488, 

1.0 

0.0 

2.4251623, 

0.0  1.0  0.0 

2.4018252, 

0.0 

1.0 

0.0 

0.0 

2.3084767, 

1.0 

0.0 

2.355151, 

0.0  1.0  0.0 

2.3318138, 

0.0 

] 

} 

] 

} 

] 

} 

ROUTE  TouchBot . isActive  TO  Clock. set_enabled 

ROUTE  Clock. fraction_changed  TO  BotPath. set_fraction 
ROUTE  Clock. fraction_changed  TO  BotAngle. set_fraction 
ROUTE  BotPath. value_changed  TO  BOTMOV. set_translation 
ROUTE  BotAngle. value_changed  TO  BOTMOV. set  rotation 
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APPENDIX  D:  SAMPLE  DYNAMIC  C  DETECTION  AND 
TRACKING  ALGORITHM 


This  appendix  lists  the  detection  and  tracking  algorithm  portion  of  an  actual 
Dynamic  C  program  used  in  the  SE  3015  Robot  Wars  competition.  This  code  is 
discussed  in  Chapter  IX. 
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//  File:  Excerpt  from  actual  Dynamic  C  program 
//  Author:  LT  Wm.  Ben  McNeal 
//  Robot  Wars  Detection  Algorithm 
//  Operating  Environment:  Windows 
//  Compiler:  Dynamic  C  1.1 

//  Description:  This  program  is  the  detection  and  tracking  logic  for  an  SE  3015 
robot 

//Inputs:  None 
//Outputs:  None 

//  Last  compile/run  date:  September  1997 
//Warnings:  None 


/*  SLOW  SPIN  SEARCH  */ 
if  {x<=48  &&  y<=48) { 

strcpy{buf, "4fgr4rgr")  ; 
platfonn( ) ; 


} 


if  (x>48  &&  y>48) { 

/*  FINAL  DETECTION  MODE  */ 

if  ( (x>=400  &&  y>=400)  &&  (abs (x-y) <=50) ) { 

strcpy (buf , "8fsr8fsr") ; 
platform! ) ; 


} 


/*  BOTH  EYES  EQUAL  NOTE  QUITE  THERE  */ 

if  (((x<400  &&  x>=250)  S&  (y<400  &&  y>=250) )  &&  (abs (x-y) <=50) ) { 

strcpy (buf , "afgrafgr") ; 
platform! ) } 

.} 

/*  BOTH  EYES  EQUAL  APPROACHING  */ 

if  ( ( (x<250  &&  x>=100)  &&  (y<250  &&  y>=100) )  &&  (abs (x-y) <=50) ) { 

strcpy (buf, "cfgrcfgr") ; 
platform! ) f 


} 

/*  BOTH  EYES  EQUAL  INITIAL  ACQUISITION  */ 

if  ( (x<100  &&  y<100)  &&  (abs (x-y)<=50) ) { 

strcpy (buf, "f f grf f gr" ) ; 
platform! ) ; 

} 


/*  SHARP  LEFT  TURN  DIFF>2500  */ 
if  (x-y>2500) { 
strcpy (buf, "9fsrcfgr") ; 
for ( count=0 ; count<l 00 0 ; count++ )  ; 
platform! ) ; 

) 
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/*  SLOWER  SHARP  LEFT  TURN  DIFF>1000  */ 
if  (x-y>1000  &&  x-y<=2500) { 
strcpy{buf , "Sfsrefgr") ; 
f or ( count=0 ; count<l 000; count++ ) ; 
platform ( ) ; 

} 


/*  SLOW  LEFT  TURN  DIFF>500  */ 
if  (x-y>500  &&  x-y<=1000){ 
strcpy{buf, "argrafgr") ; 
platform ( ) ; 

for (count=0;count<1000;count++)  ; 

} 


/*  LEFT  SEARCH  TURN  DIFF>250  */ 
if  {x-y>50  &&  x-y<=500) { 
strcpy(buf, ”8rgr8fgr")  ; 
platform ( ) ; 

f or ( count=0 ; count<l 0 00; count++)  ; 

) 

/*  SHARP  RIGHT  TURN  DIFF>2500  */ 
if  {y-x>2500) { 
strcpy (buf , "cf gr9f sr " ) ; 
platform ( ) ; 

f or ( count=0 ; count< 1 000; count++ )  ; 

} 

/*  SLOWER  SHARP  RIGHT  TURN  DIFF>1000  */ 
if  (y-x>1000  &&  y-x<=2500)  { 
strcpy (buf, "efgr9fsr") ; 
platform( ) ; 

f or ( count=0 ; count<10 0 0 ; count++ )  ; 

} 


/*  SLOW  RIGHT  TURN  DIFF>500  */ 
if  (y-x>500  &&  y-x<=1000)  { 
strcpy (buf,  "afgrargr")  ; 
platform ( ) ; 

for ( count=0 ; count<1000 ; count++)  ; 

} 

/*  RIGHT  SEARCH  TURN  DIFF>250  */ 
if  (y-x>50  &&  y-x<=500) { 
strcpy (buf,  "8fgr8rgr")  ; 
platform  ( ) ; 

f o  r ( count=0 ; count< 1000; count++ ) ; 


} 
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APPENDIX  E:  SIMBOT  DETECTION  AND  TRACKING 

ALGORITHM 


This  appendix  lists  the  Simbot  detection  and  tracking  algorithm  portion  of  JAVA 
source  code,  Simbot.class.  In  the  JAVA  source  code  the  function,  run _program 
contains  this  algorithm.  This  code  is  discussed  in  Chapter  IX. 
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//  File:  Excerpt  from  Simbotjava 
//  Author:  LT  Wm.  Ben  McNeal 

//  Simbot  Detection  and  Tracking  Algorithm  converted  from  excerpt  of 
Dynamic  C  Algorithm  listed  in  Appendix  D 
//  Operating  Environment:  Windows  NT,  Windows  ‘95/’97,  IRIX  6.* 

//  Compiler:  JDK  1.1.3 

//  Description:  This  program  simulates  an  actual  algorithm  used  for  robot  detection 
and  tracking 

//Inputs:  NA 
//  Outputs:  None 

//  Last  compile/run  date:  18  December  1997 
//Warnings:  None 


public  void  run_program{int  ad_rdO,  int  ad_rdl) 

{ 

//System.out.println(ad_rdO  +  ”  "  +  ad__rdl)  ; 
if  {time  <=  SCENE_TIME) 

{ 

if  (ad_rdO  <=  48  &&  ad_rdl  <==  48) 

{ 

compute^pos (-8, 8) ;  //SLOW  SPIN  SEARCH 

} 


else  if  (ad_rdO  >  48  | |  ad_rdl  >  48) 

{ 

if  (  (ad__rdO  >=  400  &&  ad__rdl  >=400)  && 
(Math.abs  (ad_rdO-ad_rdl)  <=50)  ) 

compute_pos  (8,8)  ;  //FINAL  DETECTION  MODE 


if  (  (  (ad_rd0<400  &&.  ad_rd0>=250)  &&  (ad_rdl<400  && 
ad_rdl>=250) )  && 

(Math.abs  (ad_rdO~ad__rdl)  <=50)  ) 

compute_pos (10, 10) ;  //BOTH  EYES  EQUAL  NOT. QUITE  THERE 


YET 


if  ( ( (ad_rd0<250  &&  ad_rd0>=100)  &&  {ad_rdl<250  && 
ad_rdl>=100) )  && 

(Math.abs  (ad_rd0-ad_rdl)  <=50)  ) 

compute_pos(12,12)  ;  //BOTH  EYES  EQUAL,  APPROACHING 

if  ( (ad_rd0<100  &&  ad_rdl<100)  &&  (Math. abs(ad  rdO- 
ad_rdl)<=50) ) 

compute__pos  (15, 15)  ;  //BOTH  EYES  EQUAL,  INITIAL 

ACQUISITION 

if  (ad_rd0-ad_rdl  >  2500) 

compute_pos (0, 12) ;  //SHARP  LEFT  TURN  DIFF  >  2500 


1000 


if  (ad_rd0-ad_rdl>1000  &&  ad_rd0-ad_rdl<=2500) 

compute_pos (0,14) ; //SLOWER,  SHARP  LEFT  TURN,  DIFF  > 


if  (ad___rd0-ad_rdl>500  &&  ad__rd0-ad_rdl<=1000) 
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compute_pos (-10, 10) ;  //SLOW  LEFT  TURN,  DIFF  >  500 

if  (ad_rd0-ad_rdl>50  &&  ad_rd0-ad_rdl<=500) 

compute_pos (-8, 8) ;  //LEFT  SEARCH  TURN,  DIFF  >  50 

if  (ad_rdl-ad_rd0>2500) 

compute_pos (12, 0) ;  //SHARP  RIGHT  TURN  DIFF  >  2500 

if  (ad_rdl-ad_rd0>1000  &&  ad_rdl-ad_rd0<=2500) 

compute_pos (14, 0) ; //SLOWER,  SHARP  RIGHT  TURN  DIFF  >1000 

if  (ad_rdl-ad_rd0>500  &&  ad_rdl-ad_rd0<=1000) 

compute_pos (10,-10) ;  //SLOW  RIGHT  TURN  DIFF  >  500 

if  (ad_rdl-ad_rd0>50  &&  ad_rdl-ad_rd0<=500) 
compute_pos (8,-8) ;  //RIGHT  SEARCH  TURN 


se  compute_pos (-8,8) ; 
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APPENDIX  F:  SIMBOT  SCRIPT 


This  appendix  lists  and  discusses  the  Simbot  script  described  in  Chapter  DC  and 
used  in  the  JAVA  source  code,  Sinibot.class. 

As  previously  discussed,  the  simulation  may  be  run  in  a  mode  where  the  target 
Simbot  moves  according  to  a  user-defined  script  instead  of  responding  to  a  detection  and 
tracking  algorithm.  Instead  of  using  the  Java  simulation  function  run _program,  the 
function  runjscript  is  used.  The  remainder  of  this  appendix  lists  a  sample  of  what  a 
Simbot  script  would  look  like. 
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//  File:  Excerpt  from  Simbotjava 
//  Author:  LT  Wm.  Ben  McNeal 
//  Simbot  Script 

//  Operating  Environment:  Windows  NT,  Windows  ‘95/’97,  DUX  6.* 
//Compiler:  JDK  1.1.3 

//  Description:  This  program  is  a  scripted  Simbot  target  scenario 
//Inputs:  NA 
//Outputs:  None 

//  Last  compile/run  date:  18  December  1997 
//Warnings:  None 


public  void  run_script (int  ad_rdO,  int  ad_rdl) 

{ 

if  (time  <=  SCENE_TIME) 

( 

if  (SCENE_TIME  <=  5. Of) 

{ 

compute_pos (8,8) 

} 

if  (SCENE_TIME  >  5. Of  &&  SCENE_TIME  <=10. Of) 

{ 

compute^os  (-10,10). 

} 

if  (SCENE_TIME  >  10. Of  &&  SCENE_TIME  <=20. Of) 

{ 

compute_pos (f , f ) 

} 

} 

) 

In  this  scenario,  the  Simbot  moves  for  a  total  of  20.0  seconds.  During  each 
sampling  instance  the  function  is  called  and  the  target  Simbot  is  issued  a  command  from 
the  script.  During  the  first  5  seconds  of  the  scenario,  the  target  Simbot  would  be  issued 
commands  directing  it  to  go  straight,  as  indicated  by  compute _pos(8,8).  In  the  next  5 
seconds  the  target  Simbot  would  spin  on  its  axis  as  indicated  by  compute _pos(8,8). 
During  the  last  20  seconds  the  Simbot  would  move  forward  at  full  speed.  Given  the 
method’s  ftinctionality  and  ease  of  use,  it  can  be  seen  that  there  are  endless  possibilities 
for  scripting  one  of  the  Simbots. 
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APPENDIX  G:  SIMULATION  SETUP 


This  appendix  describes  the  procedures  for  setting  up  and  using  the  Simbot 
simulation.  These  steps  assume  that  the  user  is  familiar  with  compiling  and  running  a 
program  in  Java  and  VRML.  A  VRML  browser  (plug-in)  must  be  used  in  conjunction 
with  Netscape  Navigator  or  Internet  Explorer  to  view  the  animated  Simbot  replication. 

STEP  1:  Decide  which  version  of  the  simulation  is  to  be  run. 

1 .  Mode  1  -  Simbot  1  uses  algorithm  while  Simbot  2  remains  in 
fixed  position  on  playing-field  (Simbotl  java) 

2.  Mode  2  -  Simbot  1  uses  algorithm  while  Simbot  2  uses  script 
(Simbot2.java) 

3 .  Mode  3  -  Both  Simbots  use  algorithms  (Simbot3  java) 

STEP  2;  Determine  initial  starting  position  and  orientation  of  Simbots  using 
playing-field  coordinate  system  illustrated  in  Figure  A-1 . 

STEP  3:  Measure  and  record  robot  input  parameters  using  Table  6-1 . 

STEP  4:  Open  appropriate  simulation  program  (i.e.,  Simbotl. java). 

STEP  5:  Goto  main  function  in  program  (at  bottom). 

STEP  6:  Enter  parameters  in  set  function  for  appropriate  robot  (i.e., 

Simbotl.set(robotX,robotY,robotZ,...).  If  no  values  are  entered, 
default  values  will  be  assigned  to  each  parameter. 

STEP  7:  Save  program. 

STEPS:  Compile  program. 
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STEP  9:  Run  program. 


STEP  10:  Open  VRML  file  (Simbot.wri). 

STEP  11:  Open  key  and  data  interpolator  files  and  copy  and  paste  data  into 

appropriate  section  of  VRML  file.  Appendix  B  shows  the  data  in  the 
interpolator  files.  In  the  VRML  file 
STEP  12:  Save  and  close  VRML  file. 

STEP  13:  Open  internet  browser  with  appropriate  VRML  plug-in  and  load 
VRML  file. 

STEP  14:  Watch  Robot  Wars!  I ! 
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Figure  A-1.  Simbot  playing-field  coordinate  system. 
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APPENDIX  H:  ONLINE  RETRIEVAL  OF  THESIS 
AND  SOURCE  CODE 


This  thesis  is  online  in  both  Postscript  and  HTML  format  at  the  following  location: 
http  ://www.  stl.nps.  navy .  mil/~auv/cs4472/co  msys.html 
The  source  code  used  in  the  thesis  is  also  available  at  the  above  address. 
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